CryptographicException: Keyset does not exist #2584
Comments
|
I'm not able to immediately reproduce this. Can you provide the full log? |
|
log-20240518.txt |
|
It's a weird error that I can't really explain, but here is a build with a potential fix and also adding some more logging that might provide additional hints. Please try it if you get a chance.
|
|
I wonder if the ephemeral key used in creating the temp pfx is being lost before the export somehow, I think you may need to PersistKeySet if using MachineKeySet (in your fallback) though as I think the export will try to read from disk not from memory. dotnet calls out to OS functions that are quite old: https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-pfxexportcertstore |
|
This version also does not work, when you want to renew the certificate, the error is still present. |
|
i see new error: The local system certificate with footprint fc 15 ee f6 66 2b c4 94 dc 26 bd ab 2f 85 d3 b4 58 e9 62 df is about to expire or has already expired. mybe is this the problem |
Ugh, indeed. Dealing with Anyway, I tried your suggestion of adding the EDIT: see below for 1701. |
|
I also have the same issue. The .1685 doesn't solve the problem. |
|
This seems to be a new bug introduced in 2.2.9, I'm revoking the release and gone back to testing. |
|
I'm currently working on a fix for this by moving to BouncyCastle as much as possible for certificate and key handling, only at the very final stages of the Certificate Store plugin it will be moved to Windows, hopefully keeping the "Bad Data" bug away while also not running into this error. There's a lot of testing to be done yet with different store types and settings, but anyone feeling adventurous can try build 1688 here: EDIT: see below for 1701. |
|
Thanks for trying to achieve a fix, but this isn't also working. And a little bit later: 2.2.8.1635 isn't working also, at least I got the last error. |
|
Hi @bieba, thanks for testing. My current theory is that all this is triggered somehow (under some circumstances, unfortunately not on my own machine) by the password protection of the temporary certificates, so I've removed that in build 1690. Would you mind giving that a spin? EDIT: see below for 1701. |
|
Nope :-/ Regarding the last error, maybe a idea: I have been looking at the certificates, they have not the exportable property set, is that necessary? I didn't change anything and because of another issue of a older version, I thought migration to a recent version would be a good idea. It is a german localized windows server 2016. |
|
Bigger problem. The client destroys the bindings which it wanted to update, because it can't assign the certificate. As I tried to choose it manually, I got the same error message. I had to rollback to the last working one.
Now the server has multiple corrupt certificates. I hope that this is not happen to many others. |
|
for me this version work super fine win-acme.v2.2.9.1688 |
|
@WouterTinus I got this same error. In my case it seems to be that this version is not properly accounting for While digging into it via Fiddler, in the ACME server response one of the certificates returned appeared to be corrupted until I use the "click to decode" option. I suspect that win-acme is also failing to do this decoding step and jumps straight to decoding the PEM data which has a chunk header right in the middle of the base64 data. |
|
The customer has a important appointment tomorrow, I am allowed to give it a new try in the late evening, not now. I come back with some news late tomorrow evening. |
|
i have winsrv2016 standard |
|
@jshall: to be clear, which error, which build of win-acme and which version of Windows? |
|
Windows version: Microsoft Windows Server 2016 Standard (10.0.14393) win-acme log excert: raw Fiddler capture: |
|
So I managed to get my hands on a Windows 2016 machine and was able to reproduce and fix the issue. Build 1700 is now available from EDIT: see below for 1701. |
|
Thanks! I can confirm that build 1700 worked for me as well. |
|
I missed it at first, but another bug popped up. The log does not directly indicate an error, but the CertificateStore plugin did not actually add the new certificate to the Windows certificate store. 2.2.8.1635: 2.2.9.1700: |
|
Looks like certificates with EC keys were slipping through the cracks in the new control flow, there's a bugfix here: |
|
.1701 tested. Works like a charm. |
|
Build 1701 has been release as version 2.2.9.1. Hopefully working for everyone now 👍 |
Error requesting certificate "[Manual] project.iztoknet.com"
System.Security.Cryptography.CryptographicException: Keyset does not exist
at System.Security.Cryptography.X509Certificates.StorePal.Export(X509ContentType contentType, SafePasswordHandle password)
at System.Security.Cryptography.X509Certificates.X509Certificate2Collection.Export(X509ContentType contentType)
at PKISharp.WACS.DomainObjects.CertificateInfo..ctor(X509Certificate2Collection rawCollection)
at PKISharp.WACS.DomainObjects.CertificateInfoBc.GenerateInner(Pkcs12Store store, X509KeyStorageFlags flags)
at PKISharp.WACS.DomainObjects.CertificateInfoBc..ctor(Pkcs12Store store)
at PKISharp.WACS.Services.CertificateService.CreateAlternative(Byte[] bytes, String friendlyName, AsymmetricKeyParameter pk)
at PKISharp.WACS.Services.CertificateService.DownloadCertificate(AcmeOrderDetails order, String friendlyName, AsymmetricKeyParameter pk)
at PKISharp.WACS.Services.CertificateService.RequestCertificate(ICsrPlugin csrPlugin, Order order)
at PKISharp.WACS.OrderProcessor.GetFromServer(OrderContext context)
Originally posted by @iztokba in #2582 (comment)
The text was updated successfully, but these errors were encountered: