What's the difference between in generating CSR file from OpenSSL and IIS?

Question

I've been shown how to generate .csr files by using OpenSSL and have successfully created, converted and installed the signed certificates (.pfx files) onto some of our web servers with IIS 10.

I've now been shown by someone else how to generate .csr files directly from one of our other web servers - using the 'Create Certificate Request' function that is available in IIS 10. However - using this method, I didn't have to create a .pfx file, and I was able to install the downloaded signed certificate onto IIS without having to convert anything. So it was a lot quicker doing it this way - however, I don't understand why this method was used in this instance and not OpenSSL. Is the end result different? Can someone enlighten me please?

Answer 1

If you use the IIS console's Create Domain Certificate... option, you can only request a certificate using Microsoft ADCS's built-in Web Server template. This template has very limited capabilities and does not include the Subject Alternate Name extension mandated by all modern browsers and also includes the S/MIME Capabilities extensions which is not required for web server certificates. As this is a version 1 template you cannot change any of these.

If you opt instead to use the IIS console's Create Certificate Request... option you'll create a request which can be saved to disk. You can now submit the request to any CA. If you opt for Windows ADCS you can use the certreq.exe utility with the -attrib "CertificateTemplate:<template short name> option to specify a different template. You can even use some geekiness to add a Subject Alternate Name extension (or any other extension) to the request, but it takes some effort and an understanding of the internal workings of X.509 certificates!

If you use OpenSSL to create the certificate request, you can ask for any field or extensions that OpenSSL is capable of create - which near enough covers everything. You can submit this to the ADCS CA with certreq.exe or submit the request to a non-Windows CA. On receipt of the certificate you need to pair it up with its private key to create the PKCS#12 (or PFX) file which you import into the server. This is rather convoluted, but your certificate request can be quite flexible if required.

However, an easier option (which it seems you weren't shown) would be to request the certificate using the server (not IIS) certificate management console (certlm.msc from the Run dialogue) where you can request a certificate using any enabled template (not just Web Server). If this template is configured correctly by the ADCS admins you'll get a certificate with an appropriate Subject Alternate Name extension, no S/MIME Capability extension and the correct key usages for a web server, which you can then simply bind to the website using IIS's console. This is both flexible and convenient.

Answer 2

1. OpenSSL is external dependency. It is not shipped along with Windows, you have to download and install the tool.
2. OpenSSL is CLI (command-line interface) tool, there is no default GUI for it.
3. OpenSSL has no integration with Windows Cryptography Subsystem (CryptoAPI).
4. IIS manager provides better UX (using UI form instead of CLI), though with limited functionality. For example, you can't specify SAN extension or configure extensions in request. It is assumed that CA server is responsible to figure out required alternative names, extensions and include them in signed certificates. Some commercial CAs provide a form where you can specify alternative names along with uploaded request file.
5. IIS manager includes integration with Microsoft Active Directory Certificate Services to perform direct certificate enrollment from internal CA.

Although OpenSSL offers more flexibility in terms of what you can include in request, it requires extra work to convert and properly install all things. Windows provides certreq.exe CLI tool which offers same functionality as OpenSSL in terms of request generation. Certreq ships with every Windows installation, you don't have to install anything to get it working.

OpenSSL (on Windows) is necessary only when target application does not support Microsoft CryptoAPI and requires private keys in PKCS#1 or PKCS#8 format. CryptoAPI has terrible support for these formats because of different cryptographic stack design. In all other cases it is enough to use built-in Windows tools (MMC, certreq, certutil, etc) to perform certificate-related operations.