Certificate errors on .NET5/6 on Debian 11 (bullseye-slim) #62810
Comments
dotnet-issue-labeler
bot
added
area-System.Security
untriaged
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones, @krwq Issue DetailsDescriptionAfter 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 We've not changed how we're copying our CA certificate. Reproduction Steps
Expected behaviorCall to API works with self signed certificates when CA is copied to container image Actual behaviorException is thrown Regression?No response Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
|
I think it might be the known issue with Debian 11 running in a docker on a host with outdated libseccomp. See dotnet/dotnet-docker#3253. To verify that, can you try to open a shell in the debian 11 image (either the aspnet image or just vanilla debian 11) and attempt to run e.g. |
|
Hey @janvorli, we run apt-get update for all the images that we create and we don't get any errors from them. |
|
@kevbite thank you for your response. In that case, it is a different issue. |
|
If you do something like foreach (X509Certificate2 cert in (new X509Store(StoreName.Root, StoreLocation.LocalMachine, OpenFlags.ReadOnly)).Certificates)
{
Console.WriteLine($"{cert.NotBefore}-{cert.NotAfter}: {cert.Subject}");
}do you see your certificate? If not, then presumably bullseye changed something about the If yes, then you can try something like X509Certificate2 cert = new X509Certificate2("/usr/local/share/ca-certificates/our-private-ca.crt");
X509Chain chain = new X509Chain();
chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
Console.WriteLine($"Chain builds successfully: {chain.Build(cert)}");
Console.WriteLine("Chain Element Status:");
foreach (X509ChainElement element in chain.ChainElements)
{
Console.Write(" ");
Console.WriteLine(element.Certificate.Subject);
foreach (X509ChainStatus status in element.ChainElementStatus)
{
Console.WriteLine(" {0} ({1})", status.Status, status.StatusInformation);
}
Console.WriteLine();
}
Console.WriteLine("Chain Summary:");
foreach (X509ChainStatus status in chain.ChainStatus)
{
Console.WriteLine(" {0} ({1})", status.Status, status.StatusInformation);
}to see if there's anything interesting reported about it. |
|
Hey @bartonjs I've run the following tests by adding the code you supplied to the startup and these are the results comparing the base docker image and also the runtimes. mcr.microsoft.com/dotnet/aspnet:5.0-buster-slimFROM mcr.microsoft.com/dotnet/aspnet:5.0-bullseye-slimFROM mcr.microsoft.com/dotnet/aspnet:6.0-bullseye-slimThey all seem to find the certificate but they all also don't output anything for the Chain Summary. |
Yeah, the Summary only contains things that went wrong. Since it counted as a trusted certificate on all of the configurations (and it's not expired, or more rare problems) the chain built successfully, and there were no errors to report. So the problem isn't that your private root isn't getting trusted.
NotSignatureValid (which should really have been called SignatureNotValid, but whatever) means that the best candidate it could find at some level didn't have a public key that worked with the issued certificate's signature. Your best bet is probably to register a custom certificate verification routine, and print out the chain information (same as before, but starting with It may also be interesting to print what's in |
|
Hey @bartonjs, thanks for the help so far, I've just run the above tests, and this time we get completely different outputs between buster-slim and bullseye-slim. However, I'm not sure where we go from here. Below are all the outputs. mcr.microsoft.com/dotnet/aspnet:5.0-buster-slimmcr.microsoft.com/dotnet/aspnet:5.0-bullseye-slimmcr.microsoft.com/dotnet/aspnet:6.0-bullseye-slim |
|
@kevbite are you able to supply the public certificate here? Another thing to try for your self-signed certificate in the container: This might print our additional details for what OpenSSL itself might not like the self-signed certificate. Perhaps we're running in to something like #47215. |
|
The My guess is that between buster and bullseye they upgraded versions of OpenSSL and it's no longer willing to build that chain. |
I guess that is something I misunderstood, I assumed from the original post this is a self signed certificate. |
|
@bartonjs yep you're correct they do both have the same subject 🤔 |
|
Do the certificates have an Authority Key Identifier / Subject Key Identifier extension? If not then this sounds like #31569. |
|
We don't have either an Authority Key Identifier or Subject Key Identifier extension. Just reading through that post and it seems very similar, I'll investigate maybe getting these changed and try again. Thanks! |
|
@vcsjones I think I missed one of your earlier messages about getting OpenSSL to verify the chain and this is the output between the 2 debain images. mcr.microsoft.com/dotnet/aspnet:5.0-buster-slimmcr.microsoft.com/dotnet/aspnet:6.0-bullseye-slim |
|
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. |
|
Thanks for all the help, it's been great getting to the end of it. I've actually learned a lot along the way! |
ghost
locked as resolved and limited conversation to collaborators
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
AuthenticationExceptionwhen talking to external APIs that are using a certificate generate by a custom CA:We've not changed how we're copying our CA certificate.
Reproduction Steps
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
The text was updated successfully, but these errors were encountered: