Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to download new certificates #51

Open
sjmjustin opened this issue Mar 1, 2024 · 7 comments
Open

Fails to download new certificates #51

sjmjustin opened this issue Mar 1, 2024 · 7 comments

Comments

@sjmjustin
Copy link

Describe the bug
When running WinCertes for renewals or new certificates, it returns an error (bubbled up from the underly certes implementation, I believe):

Generated orders and validated challenges for domains: [my domain name]
Failed to retrieve certificate from CA: Can not find issuer 'C=US,O=Internet Security Research Group,CN=ISRG Root X1' for certificate 'C=US,O=Let's Encrypt,CN=R3'.

To Reproduce
Attempt to issue a renewal on an existing cert or issue a new one for a brand new host, for example:
WinCertes.exe -e [my-email] -d [my-host.domain.com] -w=c:\inetpub\wwwroot -b "Default Web Site" -p

Expected behavior
Expect it to download and install the certificate, but instead gets a CA error. The domain, DNS, local path, etc. are correct and the challenge gets verified, but it will not download the newly issued certificate.

Additional Information
Apparently Let's Encrypt made changes to their dependencies to shorten the trust chain and certes included with WinCertes is not compatible with their new root and/or intermediate certificates and refuses to download newly-issued certs and renewals as a result.

Operating System is Windows Server 2012 R2. Using the Let's Encrypt live environment.

@webprofusion-chrisc
Copy link

Is ISRG Root X1 definitely installed in your Local Machine certificate store under Trusted Root Certification Authorities? Your server should be automatically updating it's own CA Roots. WinCertes does attempt to load issuers from the certificate store, but I have not idea if it's doing that successfully.

@sjmjustin
Copy link
Author

I checked the Windows Trusted Root Certificate Authorities store and the "ISRG Root X1" is present there (expires 2035), and is also at the root of my existing Let's Encrypt Certificate chains. The existing ones use R3 as an intermediate cert which is also present in the certificate store as an intermediate cert authority.

@sjmjustin
Copy link
Author

Based on a similar error in other libraries, it looks like Let's Encrypt made a change to their root and the underlying certes library is using an outdated root internally and would need to be updated.

Chatter on another project with the same error: fszlin/certes#315
Community discussion: https://community.letsencrypt.org/t/can-not-find-issuer-c-us-o-internet-security-research-group-cn-isrg-root-x1-for-certificate-c-us-o-lets-encrypt-cn-r3/208268/1
Let's Encrypt Announcement: https://letsencrypt.org/2023/07/10/cross-sign-expiration.html

From their announcement:

"If you are an ACME client author, please make sure that your client correctly downloads and installs the certificate chain provided by our API during every certificate issuance, including renewals. Failure modes we have seen in the past include a) never downloading the chain at all and only serving the end-entity certificate; b) never downloading the chain and instead serving a hard-coded chain; and c) only downloading the chain at first issuance and not re-downloading during renewals. Please ensure that your client does not fall into any of these buckets."

It would seem that the underlying certes library is encountering one of these described failure scenarios.

@webprofusion-chrisc
Copy link

Ok, it's up to the maintainer to investigate if they want to fix it. You could try working alternative clients like https://certifytheweb.com (which I develop), https://win-acme.com or https://poshac.me depending on your requirements and preferences.

@pgordinho
Copy link

Same problem here. Anyone has a solution for this or it must be the changed in wincertes?
I have less that 15 days to renew, so if there's no solution I must change to another client.

@anawe22
Copy link

anawe22 commented Apr 11, 2024

I can confirm that migration to https://github.com/do-know/Crypt-LE was pretty easy and latest version working well.
The only problem was the need of adding mime-type "text/plain" to "." (no extension)
So bye. Until LE64.exe stops working again :-)))

@Hyldahl
Copy link

Hyldahl commented Apr 20, 2024

Updating the nuget package references to latest versions resolves this issue.
You can do this yourself and recompile.

Or you can use one of the forks:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants