Generate Certificates and CRLs - Exercises

Try out the following exercises intended to strengthen your knowledge by allowing you to test and solve tasks on your own.

The following exercises complement How to Generate Certificates and CRLs and the Training - PKI at the Edge (session 2)) which introduces useful concepts and provides additional context.

Exercises

RFC 5280 says that a V3 certificate used as a trust anchor must contain a Basic Constraints extension and a Key Usage extension with both marked critical. The Key Usage extension needs to have keyCertSign set and possibly cRLSign if the trust anchor will sign its own CRL as well. Basic Constraints must assert CA. Modify the trust anchor certificate method to produce a version 3 certificate with the appropriate extensions.
Looking back to the first session How to Generate Key Pairs and Certification Requests, try adding a BasicConstraints extension to a PKCS10 request. The extension should indicate that the certificate is to be used as a CA certificate but that any certificate it signs must be an end entity certificate.
ADVANCED Java provides an API for interpreting Certificate Paths (also known as Certificate Chains) - the CertPath API. This includes a class for building a certificate path from a trust anchor to a given end entity, the CertPathBuilder, and a class for validating a certificate path, the CertPathValidator. Generate a trust anchor, CA certificate, and end entity certificate and see if you can validate the certificate path they form. Try changing the path so it is incorrect or revoking the end entity certificate to see what happens.

For the initial validation, you will need to create CRLs for the trust anchor and the CA certificate. You can also find examples of use in the BC provider test code.
After requesting the certificate from EJBCA, the JSON response is printed to the screen. For example, this is what it may look like:
BASH
```
  {
      "certificate": "<a base64 encoded certificate>",
      "serial_number": "4401724EF85A6C831A67BDB36B865459DF734559",
      "response_format": "DER"
  } 
```
Add a bit of code at the end to parse the certificate and print the subject DN. The certificate in the response is base64-encoded. Bouncy Castle contains a base64 decoder (look in the package org.bouncycastle.util.encoders). Once you have the certificate as a byte array, you can parse it using the CertificateFactory provided by Bouncy Castle.
If you look closely at the certificate you received, you can see that the key usage and basic constraints extension are added to the certificate although they were not present to the CSR. This is because the certificate profile in EJBCA specifies that these extensions must exist, and EJBCA will make sure they are put in correctly.