runtime: Certificate errors on .NET5/6 on Debian 11 (bullseye-slim)
Description
After changing our base image for our aspnet core sites to use the newer Debian image (buster-slim to bullseye-slim) we seem to have started getting AuthenticationException
when talking to external APIs that are using a certificate generate by a custom CA:
System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: NotSignatureValid, UntrustedRoot
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: NotSignatureValid, UntrustedRoot
at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ExceptionDispatchInfo exception)
at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions sslAuthenticationOptions)
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
We’ve not changed how we’re copying our CA certificate.
COPY our-private-ca.crt /usr/local/share/ca-certificates/our-private-ca.crt
RUN chmod 644 /usr/local/share/ca-certificates/our-private-ca.crt
RUN update-ca-certificates --verbose
Reproduction Steps
- Self Sign a certificate
- Copy the CA for that certificate to a Debian 11 image
- Call API with .NET code
- View Exception
Expected behavior
Call to API works with self signed certificates when CA is copied to container image
Actual behavior
Exception is thrown
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 17 (10 by maintainers)
Thanks for all the help, it’s been great getting to the end of it. I’ve actually learned a lot along the way!
Since it reproduces in the OpenSSL CLI that explains the observed behavior change for .NET - we’re just reporting what OpenSSL tells us. I think at this point the best course of action would be to
Doing one or the other will probably resolve the issue, doing both is also fine.