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 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. See Custom Handling of Certificate Request in CMP.
EJBCA OCSP can answer OCSP Unid requests, sending back the Fnr to authorized clients. See Unid CMP Configuration.
EJBCA OCSP has a Unid client implementation, see Fnr-Unid Client.
For the Unid Lookup part, 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 return 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 returned Fnr is null, there are several possible issues:
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).
Setting up the Unid-Fnr OCSP Extension in the OCSP/VA Server
The following describes how to set up handling of Unid extensions using the external OCSP responder and should be read in combination with the section OCSP Management.
Configuring the Unid lookup server
The OCSP responder comes with an extension for looking up Unid-Fnr mappings.
To enable the Unid extension, configure the following options for the appropriate OCSP Key Binding:
Edit the OCSP Key Binding.
Under OCSP Extensions, select Unid Fnr.
Click Add and save the key binding.
To make Unid extension available in EJBCA, the property unidfnr.enabled must be set to true in the ocsp.properties before deploying EJBCA.
The following configuration is available for the Unid extension. For information on all available OCSP options, refer to the ocsp.properties.sample.
Should be set in the JBoss CLI, using the following command (assuming MySQL with MariaDB driver is used):
All clients to 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). Use the following parameters (where differing from default) when issuing keystores to the clients:
When a certificate has been issued for a lookup client, it must be added in Trusted Certificates for the OCSP Key Binding. Each added certificate (Serial number hex) must match its issuing CA under the Certificate Authority column.
Configuring TLS on the Unid Lookup Server
This does not apply if you are running the OCSP server integrated with EJBCA, as TLS then is setup by EJBCA.
On a stand-alone OCSP server, you need to configure TLS with client authentication, requiring a JKS keystore for the key and certificate for the server. Use these parameters (where differing from default) when issuing keystores to the TLS servers:
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 machine's fully qualified DNS name used to call the server. For example CN=ocsp.primekey.com. For 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.
Place the keystore for the TLS server in the file p12/tomcat.jks on the external OCSP responder to allow it to be deployed correctly when using ant ocsp-deploy, and you will not have to change the server.xml file which is over-written by ant ocsp-deploy.
Security of the Lookup Server
The lookup server always checks that each client is using TLS with client authentication, that the certificate is valid and is one of the certificates placed in the directory pointed to by ocsp.unidtrustdir.
Note that if these conditions are not met, no Fnr is returned.
Unid CMP Configuration
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 following requirements apply:
The database table is assumed to be identical to that of the OCSP UNID/FNR implementation (often the same database).
The certificate request is assumed to be performed with CMP.
The UNID feature is activated as described in the Custom Handling of Certificate Request section in CMP.
A Unid datasource called java:/UnidDS is configured in the application server. Note that this must be a 'no-tx-datasource', just like the OCSP publisher datasource. For information on how to create this manually, see OCSP Management.
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, the 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.