Generating a certificate signed by our local Enterprise CA
Professional IT Troubleshooter with over thirty years of experience.
Published:
Browse All Articles > Generating a certificate signed by our local Enterprise CA
So you have already heard all the reasons why self-signed certificates are not ideal, and you are ready to take the next step. You have added a Windows Enterprise Certificate Authority (CA) to your environment, and you are ready to start issuing certificates, but are now stuck. Really, I’m my own target audience for this article. In the past, I’ve found myself in need of certificates, and while creating templates on the CA is relatively easy, requesting those certificates and getting them in the right place has been harder. This article is the compilation of my notes from those past experiences, hopefully a little more readable and a lot more accessible.
There are good articles that describe how a PKI Infrastructure works, and it would be a good idea to be familiar with the basics before we get started. In short, a certificate has a public part and a private part. Something encrypted with the private part is digitally signed and can be confirmed using the public part of the certificate. Something encrypted with the public public is considered encrypted, and can only be decrypted with the private part. We want to create a new certificate and get our CA to sign the certificate, indicating that if the CA is trusted, our new certificate should be trusted too.
When a certificate is needed (that is not automatically created and enrolled invisible in the background), I usually create certificates on my Windows Servers with the certreq utility that is built into Windows and makes use of the Windows certificate store. Applications and services that make use of Microsoft Cryptography features will use the Windows certificate store as well.
Although we will not be using it today, another useful tool you might consider adding to your PKI toolbox is OpenSSL, an open source toolkit I have used when creating certificates not be consumed by Windows applications. Pointers to a compiled binary version for Windows are available. While a certificate from the Windows certificate store can be exported to a file and imported into a Java keystorefor example, manipulation of the file formats is frequently necessary, manipulation that can also be accomplished with the OpenSSL tools.
The first step in creating a certificate request with certreq is creating an INF file that provides a variety of options which will define some of the capabilities of the certificate we will be created. A list of common options can be found in the “ Certreq –new” documentation, and at a minimum you need to define a [NewRequest] section which must contain at least one entry.
One section of the INF I wish I’d known about in years past is the Subject Alternate Name (SAN) extension. A SAN is intended to allow a single certificate to be used for multiple names; for example, the same certificate could be bound to a website and respond to the host name, IP address, or website alias without generating a mismatched certificate error. The SAN can be specified using the INF file by adding an [Extensions] section and using a tag of 2.5.29.17 with a property value of “{text}”, and _continue_ lines with the desired alternate names.
Please consider security as you add these alternate names however, as the values will be plainly visible in the certificate for anyone to see; in other words, an attacker will be able to see the value entered for IP Address if included in the SAN value on the certificate. Finally, in the [RequestAttributes], you can specify which template on the Windows Enterprise CA you want to apply to your request. You do not have to specify the template when generating the request; it can be included in the command line request when you submit the certificate.
As a sample, here is my NewCert.inf file.
My next step will be to open an Administrator Command Prompt window, and execute:
Assuming we have a functional Enterprise CA, we’ll next execute:
certreq –submit newcert.req newcert.cer
(And at this stage, if we've been handed a certificate from a third party app without template information, we can submit the certificate as "certreq -attrib "CertificateTemplate:<templatename>"", and the program will ask which file is being submitted.)
A dialog will open asking which available CA we wish to have sign the certificate. After a very brief pause, if we have enroll permissions and the certificate does not require administrator approval, the signed certificate will be written to the .cer file. If the certificate request is pending, in a state of “Taken Under Submission”, then make a note of the RequestID, you will need it later. After an administrator approves the pending certificate, you can retrieve the certificate:
There are good articles that describe how a PKI Infrastructure works, and it would be a good idea to be familiar with the basics before we get started. In short, a certificate has a public part and a private part. Something encrypted with the private part is digitally signed and can be confirmed using the public part of the certificate. Something encrypted with the public public is considered encrypted, and can only be decrypted with the private part. We want to create a new certificate and get our CA to sign the certificate, indicating that if the CA is trusted, our new certificate should be trusted too.
When a certificate is needed (that is not automatically created and enrolled invisible in the background), I usually create certificates on my Windows Servers with the certreq utility that is built into Windows and makes use of the Windows certificate store. Applications and services that make use of Microsoft Cryptography features will use the Windows certificate store as well.
Although we will not be using it today, another useful tool you might consider adding to your PKI toolbox is OpenSSL, an open source toolkit I have used when creating certificates not be consumed by Windows applications. Pointers to a compiled binary version for Windows are available. While a certificate from the Windows certificate store can be exported to a file and imported into a Java keystorefor example, manipulation of the file formats is frequently necessary, manipulation that can also be accomplished with the OpenSSL tools.
Creating the Certificate:
The first step in creating a certificate request with certreq is creating an INF file that provides a variety of options which will define some of the capabilities of the certificate we will be created. A list of common options can be found in the “ Certreq –new” documentation, and at a minimum you need to define a [NewRequest] section which must contain at least one entry.
One section of the INF I wish I’d known about in years past is the Subject Alternate Name (SAN) extension. A SAN is intended to allow a single certificate to be used for multiple names; for example, the same certificate could be bound to a website and respond to the host name, IP address, or website alias without generating a mismatched certificate error. The SAN can be specified using the INF file by adding an [Extensions] section and using a tag of 2.5.29.17 with a property value of “{text}”, and _continue_ lines with the desired alternate names.
Please consider security as you add these alternate names however, as the values will be plainly visible in the certificate for anyone to see; in other words, an attacker will be able to see the value entered for IP Address if included in the SAN value on the certificate. Finally, in the [RequestAttributes], you can specify which template on the Windows Enterprise CA you want to apply to your request. You do not have to specify the template when generating the request; it can be included in the command line request when you submit the certificate.
As a sample, here is my NewCert.inf file.
[NewRequest]
; At least one value must be set in this section
Subject = "CN=MGMTPC.test.local,OU=Secret Lab Dept,O=Evil Inc.,L=Anytown,S=GU,C=US"
ExportableEncrypted = true
KeyLength = 2048
; MachineKeySet set true means the computer will own certificate.
; Without the setting, ownership goes to the current user.
MachineKeySet = true
; A friendly name so I can find my certificate later.
FriendlyName = "My Testing Webcert"
[Extensions]
; This is our Subject Alternate Name, see notes about security in text.
; These are other names which can be used with the certificate
; without generating mismatched certificate errors.
2.5.29.17 = "{text}"
_continue_ = "ipaddress=192.168.16.19&"
_continue_ = "dns=website.test.local"
[RequestAttributes]
; In this case, I'm using an altered template, copied from WebServer.
CertificateTemplate = LocalWebServerMy next step will be to open an Administrator Command Prompt window, and execute:
certreq –new newcert.inf newcert.req
This will create a request file, which is just a block of text in which is encoded the settings on the certificate and the newly generated public key. In some cases, you’d either send this block of text to an administrator or public certificate authority to be signed. We will be sending that request directly to the CA.
Submitting the certificate request to be signed:
Assuming we have a functional Enterprise CA, we’ll next execute:
certreq –submit newcert.req newcert.cer
(And at this stage, if we've been handed a certificate from a third party app without template information, we can submit the certificate as "certreq -attrib "CertificateTemplate:<templatename>"", and the program will ask which file is being submitted.)
A dialog will open asking which available CA we wish to have sign the certificate. After a very brief pause, if we have enroll permissions and the certificate does not require administrator approval, the signed certificate will be written to the .cer file. If the certificate request is pending, in a state of “Taken Under Submission”, then make a note of the RequestID, you will need it later. After an administrator approves the pending certificate, you can retrieve the certificate:
certreq –retrieve [RequestID#] newcert.cer
Pulling the certificate into the local certificate store:
If everything went well, we now have a signed certificate in a file, and a public key in our certificate store. The last step to make the certificate useful will be to marry the two parts together, which we accomplish with the final certreq command:
certreq –accept newcert.cer
If you used the MachineKeySet value set to true in your INF file, your certificate will now be available to the local machine; otherwise it will be under the context of the current user.
Professional IT Troubleshooter with over thirty years of experience.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)