Thank you for sharing that, it's better than guessing
Could you try something for me?
On a windows server currently serving the wrong chain:
Download the current version of psexec (if you don't have a copy) PsExec - Windows Sysinternals | Microsoft Docs
From an administrator command prompt 'cd' to the path where psexec is.
then use the following to launch cmd as Local System: psexec -i -s cmd.exe
then launch certmgr, delete R3 issued by DST Root CA X3 from Intermediate Certification Authorities (if present, not the one issued by ISRG Root X1)
See if that helps, you can then check your served chain using openssl or qualsys ssl checker. This is how I check using openssl:
openssl s_client -servername isrg.projectbids.co.uk -connect isrg.projectbids.co.uk:443
I had previously used this method in my testing but at the time the old R3 kept reappearing after a while, which I put down to the leaf cert pointing to http://r3.i.lencr.org/ which at the time of my testing was serving the old R3 and is now serving the new R3.
The trick is impersonating local system so you can remove the old intermediate
I'm not quite sure I understand. I did not have any problem removing old intermediate, why the impersonation trick would be required?
No you're correct, I'm getting mixed up on different forum posts - you managed to get your chain serving OK so you're fine.
How do we fix this, on CENTOS?
Normally your ACME client (certboot, acme.sh, ...) provides not only the certificate (leaf) for your domain, but additional certificate(s) (intermediate signing). They also change time to time. So you have to use them. But please do not hard-code the certificates into your web server, just refer to them similar way as to the leaf certificate.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.