Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 2. Migrating TLS-e to the RHOSO deployment
The Red Hat OpenStack Services on OpenShift (RHOSO) deployment adopts the settings from the Red Hat OpenStack Platform (RHOSP) 17.1 deployment. If TLS everywhere (TLS-e) is disabled in the RHOSP deployment, it is not enabled in the RHOSO deployment.
If the director deployment was deployed with TLS-e, FreeIPA (IdM) is used to issue certificates for the RHOSP services. Certmonger, a client process which is installed on all hosts, interacts with FreeIPA (IdM) to request, install, track and renew these certificates.
The RHOSO Operator-based deployment uses the cert-manager operator to issue, track, and renew the certificates.
Because the same root certificate authority (CA) is used to generate new certificates, you do not have to modify the currently used chain of trust. Disclaimer: the below steps were reproduced on a FreeIPA 4.10.1 server. The location of files and directories may slightly change on different versions.
These instructions explain how to extract the CA signing certificate from the FreeIPA instance that is used to provide the certificates in the source environment and import it into certmanager for use in the target environment. In this way, disruption on the Compute nodes can be minimized because a new chain of trust need not be installed.
It is expected that the old FreeIPA node is then decommissioned and no longer used to issue certificates. This might not be possible if the IPA server is used to issue certificates for non-RHOSP systems.
This procedure will also need to be modified if the signing keys are stored in an hardware security module (HSM) instead of an NSS shared database (NSSDB). In that case, if the key is retrievable, special HSM utilities might be required.
Prerequisites
- Your RHOSP deployment is using TLS-e.
- Make sure the previous Adoption steps (if any) have been performed successfully.
- Make sure the backend services on the new deployment are not started yet.
Define the following shell variables. The values that are used are examples and refer to a single node standalone director deployment. Replace these example values with values that are correct for your environment:
IPA_SSH="ssh -i <path_to_ssh_key> root@<freeipa-server-ip-address>"
Procedure
To locate the CA certificate and key, list all the certificates inside your NSSDB:
$IPA_SSH certutil -L -d /etc/pki/pki-tomcat/alias
The
-Loption lists all certificates, and-dspecifies where they are stored. This will produce some output like this:Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu ocspSigningCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,PuThe item you need to consider is the first one:
caSigningCert cert-pki-ca.Export the certificate and key from the
/etc/pki/pki-tomcat/aliasdirectory:$IPA_SSH pk12util -o /tmp/freeipa.p12 -n 'caSigningCert\ cert-pki-ca' -d /etc/pki/pki-tomcat/alias -k /etc/pki/pki-tomcat/alias/pwdfile.txt -w /etc/pki/pki-tomcat/alias/pwdfile.txt
The command generates a P12 file with both the certificate and the key. The
/etc/pki/pki-tomcat/alias/pwdfile.txtfile contains the password that protects the key. You can use it to both extract the key and generate the new file,/tmp/freeipa.p12. You can also choose another password. If you choose to apply a different password for the new file, replace the parameter of the-woption, or use the-W(capital W) option followed by the password (in clear text).With that file, you can also separately get the certificate and the key by using the
openssl pkcs12command.Create the secret that contains the root CA:
oc create secret generic rootca-internal -n openstack
Import the certificate and the key from FreeIPA:
oc patch secret rootca-internal -n openstack -p="{\"data\":{\"ca.crt\": \"`$IPA_SSH openssl pkcs12 -in /tmp/freeipa.p12 -passin file:/etc/pki/pki-tomcat/alias/pwdfile.txt -nokeys | openssl x509 | base64 -w 0`\"}}" oc patch secret rootca-internal -n openstack -p="{\"data\":{\"tls.crt\": \"`$IPA_SSH openssl pkcs12 -in /tmp/freeipa.p12 -passin file:/etc/pki/pki-tomcat/alias/pwdfile.txt -nokeys | openssl x509 | base64 -w 0`\"}}" oc patch secret rootca-internal -n openstack -p="{\"data\":{\"tls.key\": \"`$IPA_SSH openssl pkcs12 -in /tmp/freeipa.p12 -passin file:/etc/pki/pki-tomcat/alias/pwdfile.txt -nocerts -noenc | openssl rsa | base64 -w 0`\"}}"Create the cert-manager Issuer and reference the created secret:
oc apply -f - <<EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: rootca-internal namespace: openstack labels: osp-rootca-issuer-public: "" osp-rootca-issuer-internal: "" osp-rootca-issuer-libvirt: "" osp-rootca-issuer-ovn: "" spec: ca: secretName: rootca-internal EOFDelete the previously created p12 files:
$IPA_SSH rm /tmp/freeipa.p12
Verify that the necessary resources were created by using the following commands:
oc get issuers -n openstack
oc get secret rootca-internal -n openstack -o yaml
After the adoption procedure is finished, the cert-manager operator is responsible for issuing and refreshing new certificates when they expire. However, since Compute services are not restarted during adoption, you need to restart the data plane (Compute) nodes before the certificates expire. Check the expiration dates of all certificates and plan accordingly.
