RH362 - ch05s02

Bookmark this page

Guided Exercise: Managing the Integrated Certificate Authority

Create an IdM certificate and manage certificate expirations.

Outcomes

Create an IdM certificate and manage certificate expirations.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise, and to ensure that all required resources are available:

[student@workstation ~]$ lab start integrated-ca

Instructions

On the idm machine, create a Network Security Services (NSS) certificate database.

[student@workstation ~]$ ssh idm
[student@idm ~]$ sudo -i
[sudo] password for student: student

Authenticate to IdM as the admin user:

[root@idm ~]# kinit admin
Password for admin@LAB.EXAMPLE.COM: RedHat123^

Create a directory to hold the NSS certificate database:
```
[root@idm ~]# mkdir ~/idmuser01-cert
```

Create an NSS certificate database using the certutil command, using RedHat123^ as the password:

[root@idm ~]# certutil -N -d ~/idmuser01-cert/
...output omitted...
Enter new password: RedHat123^
Re-enter password: RedHat123^

Create a certificate signing request (CSR), submit it to the IdM CA, then assign the certificate to the idmuser01 user.

Create a CSR. The CN attribute in the subject must match the username for the user certificates. The -n option specifies the nickname for the key:

[root@idm ~]# certutil -R -d ~/idmuser01-cert/ \
  -a -g 4096 -n idmuser01 \
  -s "CN=idmuser01, O=LAB.EXAMPLE.COM" > ~/idmuser01.csr
Enter Password or Pin for "NSS Certificate DB":RedHat123^

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

...output omitted...
Finished.  Press enter to continue:Enter

Generating key.  This may take a few moments...

Submit the CSR to the IdM CA, using the IECUserRoles profile. If you do not set this option, the default profile designed for network services is used. Use the certificate-out option to define the location of the certificate:

[root@idm ~]# ipa cert-request \
  --profile-id IECUserRoles \
  --certificate-out ~/idmuser01.pem \
  --principal idmuser01@LAB.EXAMPLE.COM \
  ~/idmuser01.csr
  Issuing CA: ipa
  Certificate: MIIFlzCCA...
  Subject: CN=idmuser01,O=LAB.EXAMPLE.COM
  Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.COM
  Not Before: Thu Jun 01 00:00:10 2023 UTC
  Not After: Sun Jun 01 00:00:10 2025 UTC
  Serial number: 18
  Serial number (hex): 0x12

Verify that the idmuser01 user has the certificate assigned:

[root@idm ~]# ipa user-show idmuser01
  User login: idmuser01
  First name: idmuser01
  Last name: idm
  Home directory: /home/idmuser01
  Login shell: /bin/sh
  Principal name: idmuser01@LAB.EXAMPLE.COM
  Principal alias: idmuser01@LAB.EXAMPLE.COM
  Email address: idmuser01@lab.example.com
...output omitted...
  Certificate: MIIFlzCCA...
  Account disabled: False
  Password: True
...output omitted...

Add the certificate to the NSS database.

Use the -n option to set the nickname, which must match the previous nickname to link the certificate with the key. The -t option sets the trust level. The -i option specifies the input certificate file:
```
[root@idm ~]# certutil -A -d idmuser01-cert/ \
  -n idmuser01 \
  -t "P,," \
  -i ~/idmuser01.pem
Enter Password or Pin for "NSS Certificate DB":RedHat123^
```

Verify that the key in the NSS database does not show orphan as its nickname:

[root@idm ~]# certutil -K -d idmuser01-cert/
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB": RedHat123^
< 0> rsa      817d6e4b3c412deda6da93f73d944c5f9b483d0f   NSS Certificate DB:idmuser01

Log out from the idm machine:

[root@idm ~]# logout
[student@idm ~]$ logout
Connection to idm closed.
[student@workstation ~]$

On the client machine, add a service principal for the vsftpd service.

[student@workstation ~]$ ssh client
[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

Authenticate to IdM as the admin user:

[root@client ~]# kinit admin
Password for admin@LAB.EXAMPLE.COM: RedHat123^

Add a service principal for the vsftpd service:

[root@client ~]# ipa service-add ftp/client.lab.example.com
----------------------------------------------------------
Added service "ftp/client.lab.example.com@LAB.EXAMPLE.COM"
----------------------------------------------------------
  Principal name: ftp/client.lab.example.com@LAB.EXAMPLE.COM
  Principal alias: ftp/client.lab.example.com@LAB.EXAMPLE.COM
  Managed by: client.lab.example.com

Create a certificate request for the ftp/client.lab.example.com principal. Save the resulting certificate in the /etc/vsftpd/certs directory.

Create the /etc/vsftpd/certs directory:

[root@client ~]# mkdir /etc/vsftpd/certs

By default, Certmonger does not create certificates in arbitrary locations. To ensure the certificate in the certs directory can be managed, configure an SELinux file context:

[root@client ~]# semanage fcontext -a -t cert_t "/etc/vsftpd/certs(/.*)?"
[root@client ~]# restorecon -R -v /etc/vsftpd/certs
Relabeled /etc/vsftpd/certs from unconfined_u:object_r:etc_t:s0 to unconfined_u:object_r:cert_t:s0

Create a certificate request for the ftp/client.lab.example.com principal. Use the -f and -k options to specify where to store the certificate and key, respectively.

[root@client ~]# ipa-getcert request -f /etc/vsftpd/certs/cert.pem \
  -k /etc/vsftpd/certs/cert.key \
  -K ftp/client.lab.example.com \
  -D client.lab.example.com
New signing request "20230601005316" added.

Verify that Certmonger is monitoring the certificate request. Use the request ID from the previous step:

[root@client ~]# getcert list -i 20230601005316
Number of certificates and requests being tracked: 1.
Request ID '20230601005316':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/etc/vsftpd/certs/cert.key'
	certificate: type=FILE,location='/etc/vsftpd/certs/cert.pem'
	CA: IPA
	issuer: CN=Certificate Authority,O=LAB.EXAMPLE.COM
	subject: CN=client.lab.example.com,O=LAB.EXAMPLE.COM
...output omitted...
	track: yes
	auto-renew: yes

Configure the vsftpd service to use TLS encryption.

Append the ssl_enable, rsa_cert_file, and rsa_private_key_file directives to the /etc/vsftpd/vsftpd.conf file:

ssl_enable=YES
rsa_cert_file=/etc/vsftpd/certs/cert.pem
rsa_private_key_file=/etc/vsftpd/certs/cert.key

Enable and start the vsftpd service:

[root@client ~]# systemctl enable vsftpd --now
Created symlink /etc/systemd/system/multi-user.target.wants/vsftpd.service → /usr/lib/systemd/system/vsftpd.service.

Test a connection to the vsftpd service. This client supports encryption of both command and data channels using TLS. Use the debug option to show the interaction:

[root@client ~]# lftp -e debug client.lab.example.com
lftp client.lab.example.com:~> user student
Password: student
lftp student@client.lab.example.com:~> ls
---- Connecting to client.lab.example.com (172.25.250.11) port 21
<--- 220 (vsFTPd 3.0.3)
...output omitted...
Certificate: O=LAB.EXAMPLE.COM,CN=client.lab.example.com
 Issued by: O=LAB.EXAMPLE.COM,CN=Certificate Authority
  Trusted
<--- 200 Always in UTF8 mode.
...output omitted...
<--- 227 Entering Passive Mode (172,25,250,11,201,10).
---- Connecting data socket to (172.25.250.11) port 51466
---- Data connection established
---> LIST
<--- 150 Here comes the directory listing.
Certificate: O=LAB.EXAMPLE.COM,CN=client.lab.example.com
 Issued by: O=LAB.EXAMPLE.COM,CN=Certificate Authority
  Trusted
---- Got EOF on data connection
---- Closing data socket
<--- 226 Directory send OK.
lftp student@client.lab.example.com:~> quit
[root@client ~]#

Log out from the client machine:

[root@client ~]# logout
[student@client ~]$ logout
[student@workstation ~]$

Renew the idmuser01 user certificate.

[student@workstation ~]$ ssh idm
[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# kinit admin
Password for admin@LAB.EXAMPLE.COM: RedHat123^

Get the key nickname used in the CSR.

Note that there is no key generated, because in this example you are using an existing one:

[root@idm ~]# certutil -K -d ~/idmuser01-cert/
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB": RedHat123^
< 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idmuser01

Create a CSR, using the -k option to provide the key nickname. Providing an existing key makes this request a renewal with the same details, rather than a new request. All attributes must be the same as the previous request:

[root@idm ~]# ipa cert-request \
  --profile-id IECUserRoles \
  --certificate-out ~/idmuser01.pem \
  --principal idmuser01@LAB.EXAMPLE.COM ~/idmuser01.csr
  Issuing CA: ipa
  Certificate: MIIFl...
...output omitted...

Add the certificate to the NSS database:

[root@idm ~]# certutil -A -d idmuser01-cert/ \
  -n idmuser01 \
  -t "P,," \
  -i ~/idmuser01.pem
Enter Password or Pin for "NSS Certificate DB":RedHat123^

Revoke the original certificate for the idmuser01 user. Use "Superseded" as the revocation reason.

Find all certificates owned by the idmuser01 user. Note the serial number of the first certificate:

[root@idm ~]# ipa cert-find --users idmuser01
----------------------
2 certificates matched
----------------------
  Issuing CA: ipa
  Subject: CN=idmuser01,O=LAB.EXAMPLE.COM
  Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.COM
  Not Before: Thu Jun 22 16:25:17 2023 UTC
  Not After: Sun Jun 22 16:25:17 2025 UTC
  Serial number: 18
  Serial number (hex): 0x12
  Status: VALID
  Revoked: False

  Issuing CA: ipa
  Subject: CN=idmuser01,O=LAB.EXAMPLE.COM
  Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.COM
  Not Before: Thu Jun 22 16:30:52 2023 UTC
  Not After: Sun Jun 22 16:30:52 2025 UTC
  Serial number: 19
  Serial number (hex): 0x13
  Status: VALID
  Revoked: False
----------------------------
Number of entries returned 2
----------------------------

Review the details of the certificate to revoke.

[root@idm ~]# ipa cert-show 18
  Issuing CA: ipa
  Certificate: ...
  Subject: CN=idmuser01,O=LAB.EXAMPLE.COM
  Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.COM
...output omitted...
  Serial number: 18
  Serial number (hex): 0x12
  Revoked: False
  Owner user: idmuser01

Revoke the first certificate by using the serial number. Use revocation code 4, meaning the certificate has been superseded.
Note
Use the certificate serial number from the previous step output. The serial number for the first certificate might be different in your environment.
```
[root@idm ~]# ipa cert-revoke 18 --revocation-reason 4
  Revoked: True
```

Verify that the certificate has been revoked:

[root@idm ~]# ipa cert-find --users idmuser01
...output omitted...
  Issuing CA: ipa
  Subject: CN=idmuser01,O=LAB.EXAMPLE.COM
  Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.COM
  Not Before: Thu Jun 01 00:00:10 2023 UTC
  Not After: Sun Jun 01 00:00:10 2025 UTC
  Serial number: 18
  Serial number (hex): 0x12
  Status: REVOKED
  Revoked: True
...output omitted...

Log out from the idm machine:

[root@idm ~]# logout
[student@idm ~]$ logout
[student@workstation ~]$

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish integrated-ca

Discuss Red Hat Security: Identity Management and Authentication

Go to community

Welcome to the Red Hat Security: Identity Management and Active Directory Integration group!

Syed

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Security: Identity Management and Active Directory Integration! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH362.Read more about Red Hat Security: Identity Management and Active Directory Integration here.

215

Revision: rh362-9.1-4c6fdb8