Describe the bug
I believe the issue I'm running into is similar to #5849. Essentially we have been using the aspnet:8.0-jammy-chiseled-extra image for our .NET 8 workloads in Azure Kubernetes Service. When we went to upgrade to .NET 9, we started running into a variety of OpenSSL errors (initialization errors, errors decoding public keys, etc). Here's an example from a service trying to decode an iText license at startup:
Unhandled exception. System.TypeInitializationException: The type initializer for 'iText.Licensing.Base.Util.SigningUtil' threw an exception.
---> iText.Licensing.Base.Exceptions.LicenseKeyException: Invalid public key.
---> Interop+Crypto+OpenSslCryptographicException: error:03000072:digital envelope routines::decode error
at Interop.Crypto.DecodeSubjectPublicKeyInfo(ReadOnlySpan`1 source, EvpAlgorithmId algorithmId)
at System.Security.Cryptography.RSAOpenSsl.ImportRSAPublicKey(ReadOnlySpan`1 source, Int32& bytesRead)
at System.Security.Cryptography.X509Certificates.OpenSslX509Encoder.BuildRsaPublicKey(Byte[] encodedData)
at System.Security.Cryptography.X509Certificates.CertificateExtensionsCommon.GetPublicKey[T](X509Certificate2 certificate, Predicate`1 matchesConstraints)
at iText.Licensing.Base.Util.CertificateWorker.CreateCertificateWorker(Stream certInputStream)... (truncated)
What I didn't see in the linked issue was any guidance on how to get past this issue. What should we be doing? We don't require FIPS (if indeed that is the issue here), so I'm not opposed to adding something to our Dockerfile to set a flag, but I would love some guidance on doing this the right way (e.g. if we did want FIPS enabled) or, alternatively, how to bypass it in a way that isn't super brittle.
Thanks!
Which .NET image(s) are you using?
aspnet:9.0-noble-chiseled-extra
Steps to reproduce
- Create a linux pod on AKS using the above image.
- Have the pod run a crypto function, such as
SHA1.Create().ComputeHash("Hello World!") as part of its workload
- Observe the OpenSSL failure
Other information
No response
Output of docker version
Output of docker info
Describe the bug
I believe the issue I'm running into is similar to #5849. Essentially we have been using the aspnet:8.0-jammy-chiseled-extra image for our .NET 8 workloads in Azure Kubernetes Service. When we went to upgrade to .NET 9, we started running into a variety of OpenSSL errors (initialization errors, errors decoding public keys, etc). Here's an example from a service trying to decode an iText license at startup:
What I didn't see in the linked issue was any guidance on how to get past this issue. What should we be doing? We don't require FIPS (if indeed that is the issue here), so I'm not opposed to adding something to our Dockerfile to set a flag, but I would love some guidance on doing this the right way (e.g. if we did want FIPS enabled) or, alternatively, how to bypass it in a way that isn't super brittle.
Thanks!
Which .NET image(s) are you using?
aspnet:9.0-noble-chiseled-extra
Steps to reproduce
SHA1.Create().ComputeHash("Hello World!")as part of its workloadOther information
No response
Output of
docker versionOutput of
docker info