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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
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 = 1.3.6.1.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.

VMware ESX – failed to install Virtual Center Agent

The error, which this post is about, can have a variety of causes. I will focus on this, which I have encountered again only because i haven’t written about it before.
The error message usually suggests improper processing of the VC Agent RPM; however, it can also signify problems running the new vpx process. vCenter reports installation success only when it receives first heartbeat from the service. It is quite possible that the service fails to start, although

1
 service vmware-vpxa restart

is executed correctly. Similarly, causes suggested by

1
 /var/log/messages

can be wrong.
This time, the problem was incorrect certificate file format. Unfortunately, VMware doesn’t recognize standard and widely used PEM format, which is provided by most Certification Authorities. Instead, it uses its own version of PEM format. It is the so-called, text PEM representation. To create such, you need to issue the following command:

1
 openssl x509 -text -in /etc/vmware/ssl/rui.crt -out /etc/vmware/ssl/rui.crt

A chance for diagnosing this mistake is interpreting of a little known log file

1
 /var/log/vmware/vpxa.log

. After experiencing this situation, the vpx agent logs there a message about impossibility of certificate file interpretation.
I think that in this log file can be helpful in other problems with vpx agent, too.