Create Server Certificates

To create server certificates, generate a PKCS12, JKS, or PEM file for the server, depending on which server is being used.

The private key is generated by the CA and you do not need to create a Certificate Signing Request (CSR) on your server for this.

To create server certificates, follow the steps below:

Step 1: Create Profiles

Create the desired profiles (the default entity and certificate profiles work fine, but are perhaps too generic). You certificate profile should have:

KeyUsage: Digital signature, Key encipherment
Extended key usage: Server Authentication

Step 2: Create Users

Create a user either using the RA Web>Make new request or the CLI command bin/ejbca.sh ra.

The Distinguished name (DN) of the server should have the the servers full hostname (host.domain.com) in the CommonName (CN) field. Example DNs:

For a webserver: C=SE,O=AnaTom,CN= www.anatom.se
For a mailserver: C=SE,O=AnaTom,OU=Engineering,CN=mail.anatom.se

You can also specify the same name (or several names) as a DNSName in SubjectAlternativeNames. For wildcard certificates, use *.anatom.se.

Set the token type to match the kind of token that should be generated for your server.

Step 3: Set Password

To allow batch-generating certificates, the batch generation program must have access to the users (servers) password in order to request a certificate on behalf of the user. Normally the password is stored in hashed form, so the password must be stored in clear text form by running:

CODE

bin/ejbca.sh ra setclearpwd <username> <password>

Step 4: Generate Private Keys and Certificates

To generate private keys and certificates, run:

CODE

bin/ejbca.sh batch

Servers require keys and certificates in different formats:

PEM format: To generate PEM files, use the token type PEM. The PEM files are stored in a separate subdirectory pem. The generated PEM files can be used with Apache, for example and are NOT protected by any password.
SUN JKS: To generate JKS files, use the token type JKS. The JKS files are stored in the subdirectory p12 instead of PKCS12-files. The generated JKS files can be used with Tomcat, for example and are protected by the users password (both private key password and keystore password).

If the server generates the keys and a certificate request (CSR) for you, select token type User generated.

You can use the RA Web pages (http://127.0.0.1:8080/ejbca/ra/) Make new request with option Provided by use" for Key-pair generation to paste the request and receive the certificate.

To use OpenSSL to transform a PKCS12 file to PEM-format, run:

BASH

openssl pkcs12 -in pkcs12-file -nodes

Copy and paste the private key to the key file, the first certificate to server cert file and last certificate to CA certificate file. If your CA is a subordinate CA to another Root CA, the CA cert file may need to contain the whole cert chain. Exactly how your server wants the files is server dependent.

HTTP over TLS

Clients implementing HTTP over TLS (such as web browsers) validate the dNSName field in the Subject Alternative Name (SAN) extension in the certificate against the domain name it is trying to connect to. The Common Name (CN) field is not used and its inclusion in certificates is discouraged. Therefore, the recommendation is to omit the CN field, mark the SAN extension as critical, and include one or more dNSNames in the SAN extension, matching the domain names clients are expecting to connect to.

IP addresses

The inclusion of IP addresses is possible but generally not recommended as most IP addresses are dynamically allocated. If the client is expected to connect to an IP address, this IP address must be included in the iPAddress field in the SAN extension.

Wildcard certificates

If a server is fronting multiple services behind a single domain name, it is recommended to use a wildcard certificate instead of listing each individual domain name in the certificate.

A wildcard domain contains an asterisk which matches a label in the domain name. For example, to issue a wildcard certificate to the domain example.com, include the two dNSNames example.com and *.example.com in the SAN extension. This certificate is valid for example.com and bar.example.com, but not for foo.bar.example.com. We refer to RFC2818 for details. Note that partial label matching is not supported in modern clients.