Ever since version 2008 it has been a well-known “feature” within Windows CA server that some certificate templates would not be available for web enrollment. The reason for this would be that some certificate features would “promote” the certificate schema version from 2 to 3. As of today, where SHA-1 is considered “dead” and Cryptography Next Generation (CNG) templates should be the only rational choice, certificates with schema version below 3 are just not available.
For most Windows based systems this is not a big problem, as certificate requests can just as easily be made from MMC certificate snap-in. But for Linux servers, or legacy appliances, not being able to generate a Certificate Signing Request (CSR) and issue a certificate based on that will imply running several “openssl” commands to “split” your manually issued certificate into private key and public certificate files – and making sure that it matches the server or appliance’s requirements.
I have often been missing the opportunity to just paste the CSR into the web enrollment portal and bring the resulting certificate back to the requesting server, but as I have been told for years that would simply not be possible for newer templates. Until recently, as I once more was facing a “CSR scenario” and came across this article from Microsoft. This was perhaps well-known for you IT pros out there, but for me this was breaking news!
The solution is quite simple, and involves nothing but a little ADSI Edit where you manually define the schema version to be something else. Be careful to test it properly, preferrably on a separate/duplicated certificate template. Because schema version 3 certificates might require data not provided through web enrollment, the workaround might not be completely safe for production environments.
This worked perfectly in my case, which was for a CentOS server, even with an X.509v3 CSR including Subject Alternate Name records.