25.8. Using SCEP with certmonger
The Simple Certificate Enrollment Protocol (SCEP) is a certificate management protocol that you can use across different devices and operating systems. If you are using a SCEP server as an external certificate authority (CA) in your environment, you can use certmonger to obtain a certificate for an Identity Management (IdM) client.
25.8.1. SCEP overview 링크 복사링크가 클립보드에 복사되었습니다!
The Simple Certificate Enrollment Protocol (SCEP) is a certificate management protocol that you can use across different devices and operating systems. You can use a SCEP server as an external certificate authority (CA).
You can configure an Identity Management (IdM) client to request and retrieve a certificate over HTTP directly from the CA SCEP service. This process is secured by a shared secret that is usually valid only for a limited time.
On the client side, SCEP requires you to provide the following components:
- SCEP URL: the URL of the CA SCEP interface.
-
SCEP shared secret: a
challengePasswordPIN shared between the CA and the SCEP client, used to obtain the certificate.
The client then retrieves the CA certificate chain over SCEP and sends a certificate signing request to the CA.
When configuring SCEP with certmonger, you create a new CA configuration profile that specifies the issued certificate parameters.
25.8.2. Requesting an IdM CA-signed certificate through SCEP 링크 복사링크가 클립보드에 복사되었습니다!
The following example adds a SCEP_example SCEP CA configuration to certmonger and requests a new certificate on the client.idm.example.com IdM client. certmonger supports both the NSS certificate database format and file-based (PEM) formats, such as OpenSSL.
Prerequisites
- You know the SCEP URL.
-
You have the
challengePasswordPIN shared secret.
Procedure
Add the CA configuration to
certmonger:[root@client.idm.example.com ~]# getcert add-scep-ca -c SCEP_example -u SCEP_URL-
-c: Mandatory nickname for the CA configuration. The same value can later be used with othergetcertcommands. -u: URL of the server’s SCEP interface.중요When using an HTTPS URL, you must also specify the location of the PEM-formatted copy of the SCEP server CA certificate using the
-Roption.
-
Verify that the CA configuration has been successfully added:
[root@client.idm.example.com ~]# getcert list-cas -c SCEP_example CA 'SCEP_example': 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 1F512279If the configuration was successfully added, certmonger retrieves the CA chain from the remote CA. The CA chain then appears as thumbprints in the command 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:
If you are using NSS:
[root@client.idm.example.com ~]# getcert request -I Example_Task -c SCEP_example -d /etc/pki/nssdb -n ExampleCert -N cn="client.idm.example.com" -L one-time_PIN -D client.idm.example.comYou can use the options to specify the following parameters of the certificate request:
-
-I: Optional: Name of the task: the tracking ID for the request. The same value can later be used with 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-timechallengePasswordPIN issued by the CA. -
-D: Subject Alternative Name for the certificate, usually the same as the host name.
-
If you are using OpenSSL:
[root@client.idm.example.com ~]# getcert request -I Example_Task -c SCEP_example -f /etc/pki/tls/certs/server.crt -k /etc/pki/tls/private/private.key -N cn="client.idm.example.com" -L one-time_PIN -D client.idm.example.comYou can use the options to specify the following parameters of the certificate request:
-
-I: Optional: Name of the task: the tracking ID for the request. The same value can later be used with thegetcert listcommand. -
-c: CA configuration to submit the request to. -
-f: Storage path to the certificate. -
-k: Storage path to the key. -
-N: Subject name in the CSR. -
-L: Time-limited one-timechallengePasswordPIN issued by the CA. -
-D: Subject Alternative Name for the certificate, usually the same as the host name.
-
Verification
Verify that a certificate was issued and correctly stored in the local database:
If you used NSS, enter:
[root@client.idm.example.com ~]# getcert list -I Example_Task Request ID 'Example_Task': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='ExampleCert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='ExampleCert',token='NSS Certificate DB' signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4 CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=client.idm.example.com,O=EXAMPLE.COM 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: true auto-renew: trueIf you used OpenSSL, enter:
[root@client.idm.example.com ~]# getcert list -I Example_Task Request ID 'Example_Task': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/private.key' certificate: type=FILE,location='/etc/pki/tls/certs/server.crt' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=client.idm.example.com,O=EXAMPLE.COM expires: 2018-05-06 10:28:06 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: true auto-renew: trueThe status MONITORING signifies a successful retrieval of the issued certificate. The
getcert-list(1)man page lists other possible states and their meanings.
25.8.3. Automatically renewing AD SCEP certificates with certmonger 링크 복사링크가 클립보드에 복사되었습니다!
When certmonger sends a SCEP certificate renewal request, this request is signed using the existing certificate private key. However, renewal requests sent by certmonger by default also include the challengePassword PIN that was used to originally obtain the certificates.
An Active Directory (AD) Network Device Enrollment Service (NDES) server that works as the SCEP server automatically rejects any requests for renewal that contain the original challengePassword PIN. Consequently, the renewal fails.
For renewal with AD to work, you need to configure certmonger to send the signed renewal requests without the challengePassword PIN. You also need to configure the AD server so that it does not compare the subject name at renewal.
There may be SCEP servers other than AD that also refuse requests containing the challengePassword. In those cases, you may also need to change the certmonger configuration in this way.
Prerequisites
- The RHEL server has to be running RHEL 8.6 or newer.
Procedure
-
Open
regediton the AD server. -
In the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP subkey, add a new 32-bit REG_DWORD entry
DisableRenewalSubjectNameMatchand set its value to1. On the server where
certmongeris running, open the/etc/certmonger/certmonger.conffile and add the following section:[scep] challenge_password_otp = yesRestart certmonger:
# systemctl restart certmonger