admin管理员组文章数量:1122832
I have a set of Let's Encrypt certificates with for each a fullchain.pem and a privKey.pem
My environment is diverse
- Docker : linux servers (debian) + window + mac
- Debug locally : window + mac
Current implementation
I used to load certificates with a LoadCertificate method like this
private static X509Certificate2 LoadCertificate(IFileInfo fullChainPem, IFileInfo privKeyPem)
{
// Create the certificate by combining the certificate and the private key
var fullChainPemContent = fullChainPem.ReadAllText();
var privKeyPemContent = privKeyPem.ReadAllText();
var cert = X509Certificate2.CreateFromPem(fullChainPemContent, privKeyPemContent);
// Create an ephemeral copy of the certificate to avoid handle issues
return new X509Certificate2(cert.Export(X509ContentType.Pkcs12));
}
I recall that creating an ephemeral copy (new X509Certificate2
) was essential in the past to avoid handle issues. However, after switching to .NET 9, I noticed that new X509Certificate2(...)
has been deprecated.
So, I updated the method to remove the ephemeral copy, as follows:
private static X509Certificate2 LoadCertificate(IFileInfo fullChainPem, IFileInfo privKeyPem)
{
// Create the certificate by combining the certificate and the private key
var fullChainPemContent = fullChainPem.ReadAllText();
var privKeyPemContent = privKeyPem.ReadAllText();
return X509Certificate2.CreateFromPem(fullChainPemContent, privKeyPemContent);
// Create an ephemeral copy of the certificate to avoid handle issues
// return new X509Certificate2(cert.Export(X509ContentType.Pkcs12));
}
The Problem
This updated code works in:
- Docker (development)
- Docker (production)
But in debug mode on window, the ASP.NET Core app fails to load the certificate.
If I re-enable the ephemeral copy (despite the deprecation warning), it works again. Without it, I get the following error on client side:
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
Running openssl s_client -connect localhost:5250
gives this output:
Connecting to ::1
CONNECTED(000001F0)
E43E0000:error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:692:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 306 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
When I restore the ephemeral copy, openssl s_client
behaves as expected, and everything works.
Key Questions
- Why does this issue only occur in debug mode?
- Why do I still need the ephemeral copy?
- What’s the proper way to fix this issue in .NET 9?
Temporary Fix For now, I replaced the deprecated code with this:
X509CertificateLoader.LoadPkcs12(data: cert.Export(X509ContentType.Pkcs12), password: null)
But I'd like to understand the root cause and find a better solution. Any insights?
I have a set of Let's Encrypt certificates with for each a fullchain.pem and a privKey.pem
My environment is diverse
- Docker : linux servers (debian) + window + mac
- Debug locally : window + mac
Current implementation
I used to load certificates with a LoadCertificate method like this
private static X509Certificate2 LoadCertificate(IFileInfo fullChainPem, IFileInfo privKeyPem)
{
// Create the certificate by combining the certificate and the private key
var fullChainPemContent = fullChainPem.ReadAllText();
var privKeyPemContent = privKeyPem.ReadAllText();
var cert = X509Certificate2.CreateFromPem(fullChainPemContent, privKeyPemContent);
// Create an ephemeral copy of the certificate to avoid handle issues
return new X509Certificate2(cert.Export(X509ContentType.Pkcs12));
}
I recall that creating an ephemeral copy (new X509Certificate2
) was essential in the past to avoid handle issues. However, after switching to .NET 9, I noticed that new X509Certificate2(...)
has been deprecated.
So, I updated the method to remove the ephemeral copy, as follows:
private static X509Certificate2 LoadCertificate(IFileInfo fullChainPem, IFileInfo privKeyPem)
{
// Create the certificate by combining the certificate and the private key
var fullChainPemContent = fullChainPem.ReadAllText();
var privKeyPemContent = privKeyPem.ReadAllText();
return X509Certificate2.CreateFromPem(fullChainPemContent, privKeyPemContent);
// Create an ephemeral copy of the certificate to avoid handle issues
// return new X509Certificate2(cert.Export(X509ContentType.Pkcs12));
}
The Problem
This updated code works in:
- Docker (development)
- Docker (production)
But in debug mode on window, the ASP.NET Core app fails to load the certificate.
If I re-enable the ephemeral copy (despite the deprecation warning), it works again. Without it, I get the following error on client side:
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
Running openssl s_client -connect localhost:5250
gives this output:
Connecting to ::1
CONNECTED(000001F0)
E43E0000:error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:692:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 306 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
When I restore the ephemeral copy, openssl s_client
behaves as expected, and everything works.
Key Questions
- Why does this issue only occur in debug mode?
- Why do I still need the ephemeral copy?
- What’s the proper way to fix this issue in .NET 9?
Temporary Fix For now, I replaced the deprecated code with this:
X509CertificateLoader.LoadPkcs12(data: cert.Export(X509ContentType.Pkcs12), password: null)
But I'd like to understand the root cause and find a better solution. Any insights?
Share Improve this question asked Nov 22, 2024 at 17:00 pierre.bpierre.b 1698 bronze badges1 Answer
Reset to default 1It doesn't have anything to do with ASP.NET, or Debug, or Docker... it's the combination of SslStream and Windows.
The TLS engine on Windows (S/Channel) doesn't do in-process cryptography, it sends it off to a secondary process so that the cryptographic keys aren't in memory when/if a process dump happens. So for your certificate (or, rather, its associated private key) what gets sent to the other process are the identifiers to pass to (e.g.) CngKey.Open to get the key loaded on the other side. Purely ephemeral keys don't have identifiers and can't be opened in another process, so it fails (just with a pretty hard to understand error).
Loading a PFX on Windows used to not have an option to load the keys ephemerally, so a well-understood side effect of PFX load is that it creates a named copy of the key (which gets deleted when you Dispose the certificate it's associated with); and that's why the export/import trick works.
You can see that it's just Windows by changing your code to
if (OperatingSystem.IsWindows())
{
return X509CertificateLoader.LoadPkcs12(
data: cert.Export(X509ContentType.Pkcs12),
password: null);
}
return cert;
and see that everything keeps working (assuming you run it on a second OS).
本文标签:
版权声明:本文标题:c# - Why does my ASP.NET Core app fail to load PEM certificates without creating an ephemeral copy in debug mode? - Stack Overfl 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1736302126a1931423.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论