Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 2. Migrating TLS-e to the RHOSO deployment
If you enabled TLS everywhere (TLS-e) in your Red Hat OpenStack Platform (RHOSP) 17.1 deployment, you must migrate TLS-e to the Red Hat OpenStack Services on OpenShift (RHOSO) deployment.
The RHOSO deployment uses the cert-manager operator to issue, track, and renew the certificates. In the following procedure, you extract the CA signing certificate from the FreeIPA instance that you use to provide the certificates in the RHOSP environment, and then import them into cert-manager in the RHOSO environment. As a result, you minimize the disruption on the Compute nodes because you do not need to install a new chain of trust.
You then decommission the previous FreeIPA node and no longer use it to issue certificates. This might not be possible if you use the IPA server to issue certificates for non-RHOSP systems.
- The following procedure was reproduced on a FreeIPA 4.10.1 server. The location of the files and directories might change depending on the version.
- If the signing keys are stored in an hardware security module (HSM) instead of an NSS shared database (NSSDB), and the keys are retrievable, special HSM utilities might be required.
Prerequisites
- Your RHOSP deployment is using TLS-e.
- Ensure that the back-end services on the new deployment are not started yet.
Define the following shell variables. The values 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> <admin user>@<freeipa-server-ip-address> sudo"
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. The
-doption specifies where the certificates are stored.The command produces an output similar to the following example:
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,Pu
-
The
Export the certificate and key from the
/etc/pki/pki-tomcat/aliasdirectory. The following example uses thecaSigningCert cert-pki-cacertificate:$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.txtNoteThe 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 the password to both extract the key and generate the new file,/tmp/freeipa.p12. You can also choose another password. If you choose a different password for the new file, replace the parameter of the-woption, or use the-Woption followed by the password, in clear text.With that file, you can also get the certificate and the key by using the
openssl pkcs12command.Create the secret that contains the root CA:
$ oc create secret generic rootca-internalImport the certificate and the key from FreeIPA:
$ oc patch secret rootca-internal -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 -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 -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 secret:
$ oc apply -f - <<EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: rootca-internal 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
Verification
Verify that the necessary resources are created:
$ oc get issuers$ oc get secret rootca-internal -o yaml
After the adoption is complete, the cert-manager operator issues new certificates and updates the secrets with the new certificates. As a result, the pods on the control plane automatically restart in order to obtain the new certificates. On the data plane, you must manually initiate a new deployment and restart certain processes to use the new certificates. The old certificates remain active until both the control plane and data plane obtain the new certificates.