The EJBCA Connector allows you to use your EJBCA to issue certificates for SmartCard-HSMs. While it has been possible to use a SmartCard-HSM as secure key store in EJBCA for quite a while, this new feature allows the use of EJBCA as certification authority backend, while the PKI-as-a-Service portal does certificate life-cycle management and manages your SmartCard-HSM population.
Connecting both cloud-based systems has some challenge though. The PKI-as-a-Service portal has an unique feature, which is that no key material is stored on the server. Whenever keys are needed, these need to be connected to the portal using Remote Smart Card Access.
EJBCA uses Mutual-TLS (mTLS) to protect access to management and CA functions. This is also the case for the SOAP interface in EJBCA, to which the EJBCA Connector needs to talk to. As mTLS requires a client key and certificate for authentication, a novel approach to protect access credentials was needed. This lead to an implementation of a mTLS client that could work with a remote SmartCard-HSM. As a result, authentication against EJBCA is always carried out with user credentials and not some system credential on the portal server. The EJBCA Connector performs mTLS with EJBCA using the private key and certificate of a SmartCard-HSM connected to the users local system.
As a prerequisite for using the connector, you first need to prepare a SmartCard-HSM and import the private key and certificate issued by the Management CA. Those are typically provided as PKCS#12 file (e.g. superadmin.p12). You can use the Smart Card Shell to import keys and certificates from a PKCS#12 container. Once you have the connector working, you can of course request client certificates via the portal.
You will need to additionally import the certificate of the Management CA, as the SmartCard-HSM is also used as trusted certificate store for the TLS server certificate. The EJBCA server certificate is typically issued by the Management CA. If some other CA issued the TLS server certificate, then you need to import the relevant CA certificates into the SmartCard-HSM.
After importing the keys and certificates, the device configuration should look like:
You can of course use the same SmartCard-HSM as token to access the PKI-as-a-Service portal. No need to have separate token.
The first step in the PKI-as-a-Service Portal is to create a Trust Center, if you have not already done so. Select “Home” / “Create Trust Center” to start the service request and provide an unique name. After that you should see the newly created trust center in “Views” / “Subjects”. Select the trust center subject to do the next steps.
From the “CA” menu select “Connect TrustCenter with EJBCA”. This service request makes this trust center a RA client of the EJBCA instance identified by it’s URL. You need to provide the URL in the form. You can freely choose the name of the EJBCA instance, it just must be an unique name in the portal.
After pressing “Save” and “Commit”, you can import profiles from EJBCA. The profile import requires authentication with the user credentials you imported above, so the SmartCard-HSM needs to be present.
Importing profiles may take a considerable amount of time, if you have a lot of CA instances and profiles. So please be patient, the process with finish eventually.
If the import of profiles from EJBCA was sucessfull, you (or any other user in the portal that can see your trust center) can request a certificate using “Home” / “Request EJBCA Certificate”. The service request will let you select a trust center visible to you and prompt for certificate related data, like your name and e-mail address. The CA instances and profiles previously imported should be available in the selection list.
If you continue with processing in the request, a fresh key pair is generated on the SmartCard-HSM connected to the client. The service request is then assigned to the RA role of your trust center for approval. By approving the request, the certification request is passed to EJBCA and the in return issued certificate in stored in the portal. The request is then assigned to the user that requested the certificate and he can finally store the certificate on this token.
Revoking the certificate is as well a function in the service request and can be done by the RA role. Once again the RA role uses his SmartCard-HSM to authenticate towards EJBCA to revoke the certificate related to this request.
If you have a running EJBCA and a SmartCard-HSM then you can try this yourself in the PKI-as-a-Service Sandbox.