Long time ago I have written about generating Certificate Signing Requests from non-Windows machines. The main goal was to sign such request by Microsoft Enterprise CA. I have mentioned vSphere infrastructure as an example.
I have been recently asked a similar question. New vSphere versions require Alternative Name Extension to exist in the certificate. The question was how to configure openssl to implement both functionalities.
Reaching the goal was quite simple, but not trivial. We can define several sections containing settings for request extensions, however only one can be used for a specific certificate request generation.
It is a good practice to reorganize an openssl configuration file designed for generating a single server certificate. In this way, we obtain templates for each server instance.
An Example configuration file may look as follows:
openssl_conf = openssl_init
[ openssl_init ]
oid_section = new_oids
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
[ new_oids ]
MsCaCertificateTemplate = 184.108.40.206.4.1.311.20.2
[ v3_req ]
basicContraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server01, DNS:server01.domena.test
MsCaCertificateTemplate = ASN1:PRINTABLESTRING:VMwareCertificate
[ req_distinguished_name ]
countrName = PL
stateOrProvinceName = Malopolskie
localityName = Krakow
0.organizationName = Firma
organizationalUnitName = Oddzial
commonName = server01.domena.test
Most important parts of the config file are:
- Line 1. Identifies the global configuration section.
- Line 4. Identifies the OIDs definitione section. This line is singleton in this section.
- Line 13. Identifies the Extension definition section. Those extensions will be added to certificate request body.
- Line 15. Defines OIDs section.
- Line 16. Defines OID registered and used by Microsoft for marking certificate template extension.
- Line 22. Defines alternative names of the server. Of course, we can use other than DNS prefixes.
- Line 23. Defines the name of certificate Template, what is designed to use during signing the certificate. It is important to remember that we need to specify “Certificate Template Name”, as oposite to “Certificate Template Display Name”.
Rest of the file is standard body similar to every single config file designed for generation of requests.
Under some circumstances after installation Windows Enterprise Operating System and configuration of AD Certification Services as Enterprise CA, the CA Services still doesn’t allow publication of certificate templates in versions higher than V1. This is because of misconfiguration of registry entries, which determines type of CA installation as Standard.
The solution for this problem is proper setup of bit flag in the CA configuration. It can be done with following command:
certutil -setreg ca\setupstatus +512
After registry update, there is necessity of restart CA service.
More over, there is possibility of manual edition of the templates list, which is used by CA for certificates enrollment. It is possible by edition of attribute
. These objects are available under following path
CN=Internal Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contonso,DC=lab
Today I’ll write about something completely new. Certification Authority Services, called AD CS (Certification Services) was added to the Windows Core distribution only in the R2 release. Windows Core themself was introduced as an installation option in the Windows 2008 release.
There is a lot of materials covering the Core installation, so I won’t describe it wider. For example, I suggest to read this Nataniel Zieliński’s article. For the moment, it is enough to know, that there is almost no graphical user interface. The system is managed from command promt. There is also very good Getting Started Guide what can help start up with Core installation, but most of new features introduced in R2 relase are still poorly documented.
The CA server installation requires using Add Role Creator on regular Windows 2008 R2, which is unavailable under Core version. So the first step is installation of service’s binaries. It can be done with following command:
start /w ocsetup.exe CertificateServices /norestart /quiet
Next really usefull step is to check corectness of installation. We can do that typing the following in the command prompt:
oclist find /i "CertificateServices"
After getting sure, that we have whole service’s package, we need to configure it. It can be done with VBScript program, which performs the automatic installation. It is available under following link. This script can help us avoid our headaches through simple and quick installation of our CA Service. But we still need to provide set of parameters which regulates its work. Full set of possible switches is provided on the script’s web page. Here, we need to pay attention that parameters:
are not supported under Core installation.
Moreover, before performing CA Service installation process in Core as well as Regular distribution we need to prepare the CApolicy.inf file, what must be placed under %SYSTEMROOT% directory. There is example code of such file:
NOTICE=Certificate issued under Test CA Policy
After the installation it is worthy to set up CDP (CRL Distribution Point) parameters with following commands:
certutil -setreg CA\DSConfigDN CN=Configuration,DC=DOMAIN,DC=LAB
certutil -setreg CA\CRLPeriodUnits 14
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:http://pki.test.domain.lab/repozitory/%%3%%8%%9.crl\n65:file://\\%%1\CertEnroll/%%3%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:http://pki.test.domain.lab/repozitory/%%1_%%3%%4.crt\n1:file://\\%%1\CertEnroll/%%1_%%3%%4.crt"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"
net stop certsvc & net start certsvc
Creation of such, or simillar script will help us ommit of “clicking off” Certificate’s parameters under remotely connected Management Console. At the end I would add, that the first article what helped me with start working with CA Services on Windows Core was this Eyalestrin’s article.