Unid FNR
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 Creating Custom Request Processors.
- EJBCA OCSP can answer OCSP Unid requests, sending back the Fnr to authorized clients. See 117380690.
- EJBCA OCSP has a Unid client implementation, see 117380690.
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 Responder 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
.
Unid Datasource | Should be set in the JBoss CLI, using the following command (assuming MySQL with MariaDB driver is used): Wildfly
CODE
JBoss
CODE
|
Trusted Certificates | 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. |
Database Tables
Create the database using the following SQL script:
CREATE TABLE UnidFnrMapping (
unid VARCHAR(250) NOT NULL DEFAULT '',
fnr VARCHAR(250) NOT NULL DEFAULT '',
rowProtection LONGTEXT,
rowVersion INT(11) NOT NULL,
PRIMARY KEY (unid)
);
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:
- 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 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.
Activation
You can configure EJBCA to generate Unids when an RA is using the CMP, REST or WS protocols. 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 Norwegian FNR to Unid Converter is selected as a Request Processor in the configuration of the CA:
- A Unid datasource called java:/UnidDS is configured in the application server. Note that this must be a 'no-tx-datasource', as specified by setting jta=false in the datasource configuration above.
Detailed operation:
- A 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.