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:

Step 4: Generate Private Keys and Certificates

To generate private keys and certificates, run:

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:

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

For more information on how browsers validate name(s) in certificates, refer to RFC2818:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.