Certificate Request generation for Microsoft Enterprise CA by openssl

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:
[cc lang=”text”]
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 =

[ 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.


Microsoft Enterprise CA doesn’t allow to publish templates V2 and V3

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.
Okno Publikacji szablonu
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 certificateTemplates in object pKIEntrollmentService. 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


MCTS Exam 70-620 – Windows Vista

Today, the moment of glory comes. I am glad to tell you about my success. From now I am Microsoft Certificated Technical Specialist – Windows Vista.
The exam is not the hardest one, but i need to forewarn all who prepare for this not to take take Windows built-in applications and installation procedures topics lightly. These are the hardest parts imo.


nmap – tool which is lacking in Windows

Nmap is one of the most intesively used by linux admins tools. It is widely known one can check out TCP port’s state on given hosts. As far as now, I was unable to find correctly working replacement for windows. Of course, there are many of migration’s attempts based on CygWin or SFU/SUA, but they require wider permissions in contrast to those that users usually have on their machines.
That is why I want to introduce you to real Microsoft replacement of this tool: PORTQRY. This tool is as usable as nmap and I can recomend it for use in every Windows Enviroments. It has one more important advantage in comparition to nmap. It can follow dynamic RPC ports used by DCOM. RPC and DCOM are heavily used by most of Windows enviroment services such as Active Directory, Certificates Service or Exchange. These are only examples of usage this technology.
Finally I wish everyone as little as possible time with network time down in yours enviroments.