Unid is a method used in Norway to map a personal number, fnr, to another number, unid. The unid is used in certificates instead of the real fnr in order to not reveal the fnr to observers. Authorized clients can make special OCSP request, with a special extension, to translate the unid back to the real fnr.
- EJBCA can generate UNID's automatically when you use the CMP protocol.
- EJBCA OCSP can answer OCSP Unid requests, sending back the fnr to authorized clients. See below for configuration.
- EJBCA OCSP has a unid client implementation. See below.
For the Unid Lookup part, you must use https with a client certificate with the ocsp client. If you use https with a client certificate and the OCSP responder is set up to answer Lookup requests, the OCSP client will returns the Fnr. The Fnr will be returned if the certificate contains a Unid in the SN component of the SubjectDN, and the Unid has a valid mapping to an Fnr in the OCSP responders Fnr-Unid mapping database.
If the Fnr returned is null, there are several possible errors:
- The client was not authorized to request an Fnr.
- There was no Unid Fnr mapping available.
- There was no Unid in the certificate (serialNumber DN component).
The OCSP responder comes with an extension for looking up Unid-Fnr mappings. To enable the Unid extension you configure the options:
in conf/ocsp.properties of the OCSP responder. All options are described in ocsp.properties.sample. There are three options for the Unid extension itself:
This should be set to a datasource configured in JBoss that goes to the correct database. the database must contain the table according to the (MySQL) definition:
CREATE TABLE UnidFnrMapping( unid varchar(250) NOT NULL DEFAULT '', fnr varchar(250) NOT NULL DEFAULT '', PRIMARY KEY (unid) );
Example of ocsp.uniddatsource is java:/UnidDS, where UnidDS is configured similarly as EjbcaDS in JBOSS_HOME/server/default/deploy/ejbca-ds.xml, but using another database.
All clients that will be allowed to lookup Unid-Fnr mapping must be issued a client certificate.
The issuer of the client certificates must be the same as the issuer of the server certificate for TLS
communication with the OCSP server (see below).
You should use these parameters (where differing from default) when issuing keystores to the clients:
- PKCS#12 files
- Extended key usage 'TLS client'
When a certificate has been issued for a lookup client, you must download the certificate from the admin-GUI of the CA and place it in ocsp.unidtrustdir. When a new certificate has been added, the OCSP application on the JBoss server must be re-deployed (you can do this with the command 'touch ejbca.ear' in JBOSS_HOME/server/default/deploy).
3. ocsp.unidcacert This is the CA certificate, in PEM format, that signed the certificates in ocsp.unidtrustdir. You can download it in PEM-format from EJBCA.
If you are running the OCSP server integrated with EJBCA you do not have to bother with this, as EJBCA set up TLS for you.
On a stand alone OCSP server you must configure TLS with client authentication. To do this you first need a JKS keystore for
the key and certificate for the server.
You should use these parameters (where differing from default) when issuing keystores to the TLS servers:
- JKS files
- Key usage: Digital Signature, Key Encipherment
- Extended key usage: 'TLS server'
The Common Name (CN) for a TLS server should be the same as the machines fully qualified DNS name used to call the server. For example 'CN=ocsp.primekey.com'.The other DN components you can choose freely.
Once the JKS keystore is issued you can configure TLS on the OCSP server in the same way as on the EJBCA server.
It is configured in the file JBOSS_HOME/server/default/deploy/jbossweb.sar/server.xml on the CA server.
The Connectors for port 8442 and 8443 is the TLS configuration.
The keystoreFile, keystorePass, truststoreFile and truststorePass are important to get right.
It is easiest if you put the keystore for the TLS server in the file p12/tomcat.jks on the external OCSP responder. When doing this it should be deployed correctly when using 'ant ocsp-deploy', and you don't have to change the server.xml file which is over-written by 'ant ocsp-deploy'.
You can configure EJBCA to generate Unids when an RA is using the CMP protocol. The generated Unids are stored in a mapping database that can be read by the OCSP responder.
- The database table is assumed to be identical to that of the OCSP UNID/FNR implementation (probably the same database).
- The certificate request is assumed to be performed with CMP.
- The UNID feature is activated as described in the Admin Guide, 'Custom handling of certificate request'
- A Unid datasource called java:/UnidDS is configured in the application server. Note that this must be a 'no-tx-datasource', just like the an OCSP publisher datasource (see Installation for instruction how to create this manually if needed).
- A Unid database must be created, see above for details on the Unid database.
- A CMP Certificate Request is performed with KeyId holding a Certificate Profile with name "pppp-pppp-..."
- The Certificate Request contains a DN serialNumber attribute holding the ll-digit FNR + 5-digt LRA according to the following:
Subject DN: CN=Alexander Rybak, serialNumber=fffffffffff-lllll, C=NO
- Now EJBCA creates a random 6-character alphanumeric string "rrrrrr" and rewrites the Subject DN so that the resulting certificate will be like:
Subject DN: CN=Alexander Rybak, serialNumber=pppp-pppp-lllllrrrrrr, C=NO
- In the database FNR is set to "fffffffffff" and UNID to "pppp-pppp-lllllrrrrrr". UNID is a primary key in the DB to guarantee that it is unique.