Below is an example of generating a private key and CSR using OpenSSL, then signing it with a registered GoDaddy domain. It’s critical that the common name and SAN’s align with the domain(s) that you’re selecting in your GoDaddy (Domain Authority) portfolio, otherwise it will not work. The .cnf file contains the request information highlighted at the top. This is what contains the fields that define what the purpose and what destination the certificate is used for. In our case, we just need to provide a couple key fields, which are the FQDN’s that we are hoping to use it with.
You can install openSSL for windows here.
openssl req -out signingrequest.csr -newkey rsa:2048 -noDES -keyout private.key -config request.cnf
The command above is broken down quite simply,
| req -out [file name] | Output a CSR file using whatever is supplied in-config and output it to the current directory. |
| -newkey rsa:2048 [file name] | Generate a new private key and defines the key size. This is also used to generate the csr/public key used in the signing process. |
| -noDES | The option -nodes is not the English word “nodes”, but rather is “no DES”. When given as an argument, it means OpenSSL will not encrypt the private key in a PKCS#12 file. |
| -keyout | specifies the output for the newly generated key that should be dumped in the current directory. |
| -config | Tell openSSL which .cnf file to use when processing the CSR request. |
OpenSSL is pretty straightforward, however, when working with windows, it can be a little more confusing. Here we will look at an example of a Windows Certificate Authority formatted config file.
Using the following command, I can point to a configuration file (like the one above) or, as a more simple example, this would be a Client Authentication certificate signing request. When defining the purpose of a certificate, there’s a string of dot-decimal numbers that correlate with the use-case called the OID [Object IDentifier]. See a list of OID’s here for a better idea.
The “CSR” would be the “req” file. This is what you hand over to the Windows CA to be signed in your environment.
certreq.exe -new policy.txt request.req
Windows likes to confuse technicians by hiding the private key that it generates until the public key (preferably the signed one) is installed [imported] into the computer/user profile. Until then, even if you view the certmgr.msc console, nothing will be seen.
Utilizing OID’s in openSSL is the same concept, just different formatting.
The Packet Blog 
Leave a comment