12.3. Requesting a CA-signed Certificate Through SCEP

The Simple Certificate Enrollment Protocol (SCEP) automates and simplifies the process of certificate management with the CA. It lets a client request and retrieve a certificate over HTTP directly from the CA's SCEP service. This process is secured by a one-time PIN that is usually valid only for a limited time.
The following example adds a SCEP CA configuration to certmonger, requests a new certificate, and adds it to the local NSS database.
  1. Add the CA configuration to certmonger:
    [root@server ~]# getcert add-scep-ca -c CA_Name -u SCEP_URL
    • -c: Mandatory nickname for the CA configuration. The same value can later be passed to other getcert commands.
    • -u: URL to the server's SCEP interface.
    • Mandatory parameter when using an HTTPS URL:
      -R CA_Filename: Location of the PEM-formatted copy of the SCEP server's CA certificate, used for the HTTPS encryption.
  2. Verify that the CA configuration has been successfully added:
    [root@server ~]# getcert list-cas -c CA_Name
    CA 'CA_Name':
           is-default: no
           ca-type: EXTERNAL
           helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL
           SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7
           SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279
    The CA configuration was successfully added, when the CA certificate thumbprints were retrieved over SCEP and shown in the command's output. When accessing the server over unencrypted HTTP, manually compare the thumbprints with the ones displayed at the SCEP server to prevent a Man-in-the-middle attack.
  3. Request a certificate from the CA:
    [root@server ~]# getcert request -I Task_Name -c CA_Name -d /etc/pki/nssdb -n Certificate_Name -N cn="Subject Name" -L one-time_PIN
    • -I: Name of the task. The same value can later be passed to the getcert list command.
    • -c: CA configuration to submit the request to.
    • -d: Directory with the NSS database to store the certificate and key.
    • -n: Nickname of the certificate, used in the NSS database.
    • -N: Subject name in the CSR.
    • -L: Time-limited one-time PIN issued by the CA.
  4. Right after submitting the request, you can verify that a certificate was issued and correctly stored in the local database:
    [root@server ~]# getcert list -I TaskName
    	Request ID 'Task_Name':
            status: MONITORING
            stuck: no
            key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB'
            certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB'
            signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B
            signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4
            CA: AD-Name
            issuer: CN=windows-CA,DC=ad,DC=example,DC=com
            subject: CN=Test Certificate
            expires: 2018-05-06 10:28:06 UTC
            key usage: digitalSignature,keyEncipherment
            eku: iso.org.dod.internet.security.mechanisms.8.2.2
            certificate template/profile: IPSECIntermediateOffline
            pre-save command:
            post-save command:
            track: yes
    	auto-renew: yes
    The status MONITORING signifies a successful retrieval of the issued certificate. The getcert-list(1) man page lists other possible states and their meanings.