-
Notifications
You must be signed in to change notification settings - Fork 29
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
Comments
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. |
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. |
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 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. |
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. |
Same problem here. Anyone has a solution for this or it must be the changed in wincertes? |
I can confirm that migration to https://github.com/do-know/Crypt-LE was pretty easy and latest version working well. |
Updating the nuget package references to latest versions resolves this issue. Or you can use one of the forks: |
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.
The text was updated successfully, but these errors were encountered: