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.
- 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 othergetcertcommands.-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.
- 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 1F512279The 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. - 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 thegetcert listcommand.-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.
- 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: yesThe status MONITORING signifies a successful retrieval of the issued certificate. Thegetcert-list(1)man page lists other possible states and their meanings.
