What is hardcore PKI?Technologies such as ASN.1 and X.509, RSA and ECC Standards and APIs are extremely complex for most users and developers, and the important process of fitting them all together in standards (to enable interoperable systems) is very hard. However, implementors of PKI systems don't have to care about these hardcore technologies due to a few helpful tools:
- ASN.1 parsing is done using the library BouncyCastle.
- Digital signatures with RSA and ECC is also done either using BouncyCastle in software, or it is done in Hardware Security Modules.
- Standardization is done by organizations such as IEFT and Oasis.
The Devil is in the DetailHardcore PKI, in my opinion, is that everybody needs and uses PKI, but always in slightly different ways. This demands from the PKI to have the ability to support a lot of different architectures (which EJBCA does) and from you to be able to configure and fine tune your PKI according to your precise needs. The devil is in the details!
Thirteen EJBCA options explainedHere are thirteen examples of hardcore details that can truly make your PKI better integrated. But unless you are looking for one or more of these specific features, these options may appear somewhat incomprehensible.
|EJBCA Certificate Profile options: override and certificate storage|
- Allow validity override – Normally validity is determined by the certificate profiles, but with this option the validity period can be taken from the request sent by the client/RA.
- Allow extension override – Normally certificate extensions are determined by the certificate profiles, but with this option the extensions can be taken from the request sent by the client/RA.
- Allow DN override – Normally the DN is pre-registered and determined by the end entity record, but with this option the DN can be taken from the request sent by the client/RA.
- Use Certificate storage – An interesting option where you can choose to not store issued certificates in the CA database. This fits specific use cases where revocation never needs to happen and you want to issue large amounts of certificates without the burden of administrating a growing CA database. A kind of fire and forget CA.
|EJBCA Certificate Profile options: CN postfix and single active certificate|
- Use CN postfix – tells the CA to add some text after the CN in the issued certificate. Can be used to get user friendly names (like 'Tomas – Encryption' and 'Tomas – Signing') in browser certificate dialogues.
- Use DN and altName subset – use this if you want to register more information about end entities, than is visible in the issued certificate.
- Approvals – enforces dual control (or four eyes principle) for certain functions such as revocation and key recovery.
- Single Active Certificate Constraint – automatically revokes an end entity's old certificate when a new certificate is retrieved. This ensures that a user or device can only use one certificate at a certain point in time.
|EJBCA Certificate Profile options: enforce public key and DN|
- Enforce unique public keys – makes two end entities unable to use the same public key.
- Enforce unique DN – makes two end entities unable to share the same subject DN.
- Enforce unique Subject DN SerialNumber - makes two end entities unable to share the same SerialNumber component in the Subject DN. The SerialNumber in the DN is typically used for device serial numbers, thus ensuring that one device is only registered as a single end entity.
- Use User Storage – when disabled, end entities are not stored in the database when issuing certificates through an RA capable protocol. Saves space in the database, but removes some functionality.
- Use Certificate Storage – when disabled, certificates are not stored in the database when issued. This option enables issuing of billions of certificates without using any storage space, but on the other hand disables several of the commonly required PKI functions such as revocation.