If you’re reading this, you’ve probably spent the last day of your life despairing as me and my colleague have during the last 24 hours.
The problem definition is a seemingly simple one: we have some resource on AWS (in our case, an ALB) to which we want to apply an SSL/TLS certificate.
Rather than use Let’s Encrypt or any other externally trustworthy source – we opted to use our internal (on-prem) AD/Windows Certificate Authority. We created a CSR, generated the certificate via the Windows Server, converted it to the PEM format, combined both the root and intermediate certificates into a single chain file (also PEM formatted), and shoved the whole lot into ACM using the “Import Certificate” feature.
And … it failed.
The only error it hinted at was:
“Could not validate the certificate with the certificate chain.”
Well, we manually verified the certificate against the chain using openssl verify locally, and even on several external web tools just to be sure. The certificate is fully verifiable using the certificate chain we supplied.
After a great deal of frustration – we finally reached out to AWS support … expecting their response to be something to the effect of “You clearly didn’t read the instructions on our website, you had the wrong line endings/didn’t format it as PEM properly/the root certificate is missing/etc”.
But no.
It turns out the error message – while I guess technically true was at best fairly misleading. The issue was with the certificate itself, specifically that the certificate’s Signature Algorithm was using RSASSA-PSS padding, aka PKCS#1 v2.1. ACM, apparently, doesn’t support this – if one is using RSA, it needs to be the “older” PKCS#1 v1.5. In Windows, this shows as a signature algorithm looking something like sha256WithRSAEncryption (as opposed to rsassaPss or thereabouts).
It’s also worth mentioning, it appears the entire certificate chain must also adhere to this requirement – although ours did (happened to) already.
The route to achieving this is not obvious… at least, not for me (who hasn’t ever worked with Microsoft’s offline CA functionality). Configuring a certificate template with the following option disabled apparently is the “fix”:
However, for us, this wasn’t enough. After much more Googling and frustration – we discovered a previous system administrator had set some sort of policy (which is driven by a text file hidden in c:\Windows on the CA server) which forces the alternative signature format to enabled – in such a way as to provide no feedback (not even a warning!) from any of the user interfaces.
StackExchange, as always, came to the rescue:
https://serverfault.com/a/743950/106136
We were fortunate, the setting had been enabled after the root and intermediate certificates had been generated. We didn’t have to replace those with new ones (as per the linked instructions above). YMMV however…
Good luck!