I am not sure why, I have deployed via Certify the web many times on many different systems, but on this Apache Tomcat web server I am getting this error. I get no errors in the cert request or deployment.
However the browser shows the error of Cipher mismatch.
Any guidance would be greatly appreciated.
Thank you in advance.
In the latest version 6.x the default private key type changed to ECDSA 256 instead of RSA so I think that might be the problem. Please review our change log from 6.x here, which includes potential Breaking Changes: Release Notes - Certify The Web - ACME for Windows, simple free certificates for IIS and more, powered by Let's Encrypt and other ACME CAs
You can change back to an RSA key under Certificate > Advanced > Signing & Security, select RSA 2048 (which was the previous default) then click Request Certificate again to get a new certificate with an RSA key.
Thank you for your answer.
However the cert is already in RSA 2048 so was the previous that was working.
Do you have any other ideas as to why this could be happening?
This sounds similar to Legacy algorithm for older servers - #3 by General_Louis
Did you use the 5.9x beta version at all before upgrading to 6.x? It seems like the app could be using the modern PFX encryption/signature algorithms instead of the standard “legacy” ones. I assuming you are using the PFX file and not converting to PEM etc.
Can you check that C:\ProgramData\Certify\appsettings.json has “UseModernPFXAlgs”: set to false?
Again thank you for all your help with this.
In regards to your latest comment:
Everything there looks right.
I do see that even though the RSA 2048 option is selected the chain for the cert is 4xxx and the cert is 2048.
The old cert is 2048 and its chain is 2048 as well.
Is there a possibility this is the issue? If so how do I resolve it?
Is the tomcat server a new install? Really you shouldn’t have to change anything on the certificate and instead you can configure the TLS level (e.g. 1.2) and the cipher suite in tomcat. The cipher mismatch problem means the server and the client can’t agree either on the protocol level or the cipher suite selection.
I don’t quite follow what you mean by the chain is 4xxx, which part of the chain and how are you verifying that? As far as I know only the leaf certificate (your end entity certificate) should really matter to the browser. If you can provide a real domain perhaps I can look at the chain and cipher suite etc.
No this is not a new install.
The server has been running for years with no issue.
By cert chain I mean while inspecting the cert chain the root of the cert is RSA 4096 on the generated cert from CTW where the old cert root is 2048.
I am inspecting the certs with keystore explorer.
Was the old root DST Root CA X3 and the new one is ISRG Root X1?
v6.0 onwards defaults Let’s Encrypt certificates to the modern chain “ISRG Root X1”, this is because the old expired DST Root CA X3 chain is largely ignored in most native windows apps.
If you need it to use the old chain set your preferred chain under Certificate > Advanced > Certificate Authority - Preferred Chain to DST Root CA X3 and request your certificate again. Note that this chain uses an expired root and should only be used for compatibility with old clients.