Error building certificate as PFX - Cannot find issuer

Hey all,

Great product this :slight_smile: I’ve recently had an issue trying to generate a test certificate. Now I’ve read online there was an issue with this on LetsEncrypt and there was scheduled maintenance 2 days ago by LetsEncrypt.
LetsEncrpt Staging Changes & this LetsEncryptStatus Here is my error:

Check system date/time is correct and that the issuing CA is a trusted root CA on this machine (or in custom_ca_certs). :Can not find issuer ‘C=US,O=(STAGING) Internet Security Research Group,CN=(STAGING) Doctored Durian Root CA X3’ for certificate ‘C=US,O=(STAGING) Internet Security Research Group,CN=(STAGING) Pretend Pear X1’. System.Exception: Failed to build certificate as PFX. Check system date/time is correct and that the issuing CA is a trusted root CA on this machine (or in custom_ca_certs). :Can not find issuer ‘C=US,O=(STAGING) Internet Security Research Group,CN=(STAGING) Doctored Durian Root CA X3’ for certificate ‘C=US,O=(STAGING) Internet Security Research Group,CN=(STAGING) Pretend Pear X1’.

  • at Certify.Providers.ACME.Certes.CertesACMEProvider.ExportFullCertPFX(String certFriendlyName, String pwd, IKey csrKey, CertificateChain certificateChain, String certId, String primaryDomainPath) in*

Do you guys know what could be causing this? Please help. I did recently update the app & I’m running version 5.3.1.0 Thanx in advance!

Hi James,

So because of the way that Certify The Web (via it’s ACME library certes) builds the PFX certificate chain we actually need a copy of the root signing certificate for whichever chain you are trying to build. Normally this is either found in the computers trust store (for trusted issuers) or in the past certes has bundled a few embedded certs for things like the LE staging root.

However, very recently Let’s Encrypt introduced a couple of staging chain roots ((STAGING) Pretend Pear X1 and (STAGING) Doctored Durian Root CA X3. This is becuase LE are planning to change their production chain and are experimenting with have a choice between an expired root (which will work on old android versions) and a non-expired root (which won’t). Which if these you need to know about will depend on which chain you are being served by default from the LE staging API. In the current case, this is (STAGING) Doctored Durian Root CA X3 - this will likely change over time.

To get the cert chain to build, you need to provide the missing root and because this is a test cert that shouldn’t be trusted you need to not install it to the trust store, instead you need to get a copy of the root cert and place it into either C:\ProgramData\Certify\custom_ca_certs\der or C:\ProgramData\Certify\custom_ca_certs\pem depending on what format you have it in.

Here is a link to Doctored Durian in DER format: http://stg-r3.i.lencr.org

Thanx for the detailed info and quick response! :grinning: Let me go put that cert there

1 Like

If somebody requires another format Staging Environment - Let's Encrypt

1 Like

Hi @webprofusion,

From James’ response it sounds like you gave the correct answer.

LE worked fine for my previous 8 domains that already had certificates, but not for the last two domains that I am trying to get certified after upgrading to v5.4.3. With previous versions there weren’t any issues, but this latest update has now started to give me this same error.

How would you tell a non security expert, like me, how to fix this? :wink:

Are you really trying to get staging (dummy) certificates or real ones? Do you have the exact same error is it something slightly different?

I am trying to get real certificates. The error that I get is:

2021-05-28 10:29:31.179 +01:00 [INF] TTN: Request failed - Failed to build certificate as PFX. Check system date/time is correct and that the issuing CA is a trusted root CA on this machine (or in custom_ca_certs). :Certification path could not be validated. System.Exception: Failed to build certificate as PFX. Check system date/time is correct and that the issuing CA is a trusted root CA on this machine (or in custom_ca_certs). :Certification path could not be validated.
at Certify.Providers.ACME.Certes.CertesACMEProvider.ExportFullCertPFX(String certFriendlyName, String pwd, IKey csrKey, CertificateChain certificateChain, String certId, String primaryDomainPath) in D:\a\certify-service\certify-service\src\certify-build\certify\src\Certify.Providers\ACME\Certes\CertesACMEProvider.cs:line 1484
at Certify.Providers.ACME.Certes.CertesACMEProvider.d__35.MoveNext() in D:\a\certify-service\certify-service\src\certify-build\certify\src\Certify.Providers\ACME\Certes\CertesACMEProvider.cs:line 1251
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Certify.Management.CertifyManager.d__17.MoveNext() in D:\a\certify-service\certify-service\src\certify-build\certify\src\Certify.Core\Management\CertifyManager\CertifyManager.CertificateRequest.cs:line 945
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Certify.Management.CertifyManager.d__16.MoveNext() in D:\a\certify-service\certify-service\src\certify-build\certify\src\Certify.Core\Management\CertifyManager\CertifyManager.CertificateRequest.cs:line 737
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Certify.Management.CertifyManager.d__14.MoveNext() in D:\a\certify-service\certify-service\src\certify-build\certify\src\Certify.Core\Management\CertifyManager\CertifyManager.CertificateRequest.cs:line 444
2021-05-28 10:34:58.066 +01:00 [INF] [Preview Mode] Completed certificate request and automated bindings update (IIS)

Can you check the Computer Certificates (certmgr.msc) under Trusted Root Certification Authorities > Certificates - you should be able to see DST Root CA X3 and ideally ISRG Root X1. When either of these aren’t available the the app can’t build and validate the certificate chain. Certify currently requires this.

Can you try opening internet explorer (or edge) on the machine where Certify is installed and browse to https://valid-isrgrootx1.letsencrypt.org/ - I suspect your server hasn’t see the ISRG Root X1 CA certificate before and if that’s the case then browsing to a site that uses it will auto install it.

Note that under normal circumstances windows update will provide trusted root CA certificates, so you should check that your machine is receiving updates and that trusted root certificates updates hasn’t been disabled (this is sometimes the case for servers controlled by group policy).

Thanks for you help so far.

The DST cert is there, but not the ISRG one. I browsed the web page you mentioned and checked again, but still no change, so the ISRG cert didn’t install. If I use IE then I can install the cert under the Trusted Root certs and it shows as valid-isrgrootx1.letsencrypt.org, but the issue still persists.

I try not to use the server browser, so the server doesn’t get to “see” many certs other than the ones that the admins push out.

Also, I see the message includes a error of the system date/time not being correct. I checked and the server is set to auto update for the region and time, so unless it is out by milli-seconds, the time should be fine.

New update: now I get the rate limit error: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours

Ok, so if the isrg root X1 is now in the trusted roots the then cert should build. You may need to restart the Certify background service as it maintains a cache of trusted roots.

The Let’s Encrypt rate limit should clear fairly soon, you can circumvent it by adding a temporary (valid) domain or subdomain into the cert.

In extreme cases you could switch to a different Certificate Authority (such as BuyPass Go or ZeroSSL) but they will also have roots that need installed.

Your server should already be maintaining trusted roots, so check that you don’t have firewall rules that may be preventing updates (outgoing https calls etc). OS updates are extremely important to maintain for internet facing servers. Ensure you are also using the latest version of Certify.

The rate limit was still preventing me from proceeding, so I changing over the Preferred CA to ZeroSSL and now the certificate has been issued and the site is secured.

Thanks very much for all your help to get this fixed enough so that I could get the cert issued.

1 Like

Great! Glad you got it working :slight_smile: