pingidentity-devops-getting-started icon indicating copy to clipboard operation
pingidentity-devops-getting-started copied to clipboard

privateCert: generate: true does not update pingfederate admin SSLServer certificate

Open gsustek opened this issue 2 years ago • 1 comments

Describe the bug If this switch is enabled: privateCert: generate: true it seems that newly generated certificates are not used / updated to pingfederate admin SSL certificate

To Reproduce Steps to reproduce the behavior: on Openshift 4.9, apply this yaml:

pingfederate-admin: enabled: true ingress: annotations: route.openshift.io/termination: "passthrough" defaultDomain: apps.test.clusters.example.com enabled: true hosts: - host: pingfederate-admin._defaultDomain_ paths: - backend: serviceName: https path: '' pathType: ImplementationSpecific tls: - hosts: - pingfederate-admin._defaultDomain_ secretName: team-cyse-pf-ns-cert privateCert: generate: true format: "PKCS12" additionalHosts: [zima] additionalIPs: [] envs: SERVER_PROFILE_URL: https://github.com/pingidentity/pingidentity-server-profiles.git SERVER_PROFILE_PATH: getting-started/pingfederate pingfederate-engine: enabled: true envs: SERVER_PROFILE_URL: https://github.com/pingidentity/pingidentity-server-profiles.git SERVER_PROFILE_PATH: getting-started/pingfederate global: workload: securityContext: null externalImage: pingtoolkit: securityContext: null

Expected behavior it should update ssl certificate on pingfederate admin listener

Screenshots /run/secrets/private-keystore/keystore.env is created and secret team-cyse-pf-pingfederate-admin-private-cert with keys are generated but not exposed on pod filesystem(maybe there is no intention of that)

Environment: Openshift 4.9

Additional Info how values from this file keystore.env or team-cyse-pf-pingfederate-admin-private-cert secret are used to substitute SSL of pingfederateadmin SSL listener(port 9999) how this can be referenced to custom openshift secret, previously generated by, as example, certmanager operator?

gsustek avatar Sep 27 '22 10:09 gsustek

The logic for generating a private cert creates that keystore.env file, and then exports those values for the scripts to use. But those variables have to actually be referenced to be applied. Currently in our default profiles, only PingAccess uses those values - see https://github.com/pingidentity/pingidentity-server-profiles/blob/fa8ffb09d69cb4eb62b40b1714c43e92e467f4c9/baseline/pingaccess/instance/data/start-up-deployer/data.json.subst#L203 .

If you'd like to make a modification to the pingfederate profile to do the same, you can use those values in the data.json.subst file. See https://github.com/pingidentity/pingidentity-server-profiles/blob/fa8ffb09d69cb4eb62b40b1714c43e92e467f4c9/baseline/pingfederate/instance/bulk-config/data.json.subst#L257 . For a workaround you can copy our pingfederate profile to your own git repo and make the modifications as necessary. We'll look at updating our default profiles to do this automatically.

Also - the secret you mentioned (...-pingfederate-admin-private-cert) only gets mounted to the initContainer, not to the running PingFederate container. The initContainer uses the tls.crt and tls.key files to generate the keystore file.

https://github.com/pingidentity/pingidentity-server-profiles/pull/113

timothynguyen90 avatar Nov 17 '22 17:11 timothynguyen90