Hi, this mail is about my take on issue https://fedorahosted.org/pki/ticket/1253 Yesterday night I had a long conversation with Ade on #dogtag-pki. He explained the install process in great detail to me. Thanks Ade! :) Do we have a logging bot in the channel or another way to store discussions for the future? Today I took the scenic route and explored the implementation of pkispawn as well as how it interacts with Tomcat over HTTPS. Ade already pointed three distinct cases. There might be a couple more case, though. I haven't tried them all yet. Case #1: creation of security domain ------------------------------------ The first case occurs during the initial installation of the security domain, when no CA cert is imported. During the installation pkispawn setups up a Tomcat instances and creates a CA. Because no CA exists in the beginning of the process, the installer uses a temporary self-signed cert for the Tomcat server instance. The self-signed cert is stored in PKI's NSS database. The name of the certificate for instance 'pki-tomcat' is 'Server-Cert cert-pki-tomcat'. This certificate is used throughout the entire installation until Tomcat is restarted. # certutil -d /etc/pki/pki-tomcat/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-tomcat CTu,Cu,Cu # certutil -d /etc/pki/pki-tomcat/alias/ -L \ -a -n 'Server-Cert cert-pki-tomcat' | openssl x509 -text Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: O=2015-08-05 14:11:10, CN=vm-089.example.com Validity Not Before: Aug 5 12:13:05 2015 GMT Not After : Aug 5 12:13:05 2016 GMT Subject: O=2015-08-05 14:11:10, CN=vm-089.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: After pkispawn has successfully spawned the CA, the trust anchor is available in NSS database, too. Its name is 'caSigningCert cert-pki-tomcat CA' for 'pki-tomcat'. 'Server-Cert cert-pki-tomcat' is replaced with a signed cert. # certutil -d /etc/pki/pki-tomcat/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-tomcat CA CTu,Cu,Cu Server-Cert cert-pki-tomcat u,u,u auditSigningCert cert-pki-tomcat CA u,u,Pu ocspSigningCert cert-pki-tomcat CA u,u,u subsystemCert cert-pki-tomcat u,u,u # certutil -d /etc/pki/pki-tomcat/alias/ -L -a -n \ 'caSigningCert cert-pki-tomcat CA' | openssl x509 -text Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: O=example.com Security Domain, CN=CA Signing Certificate Validity Not Before: Aug 5 12:26:52 2015 GMT Not After : Aug 5 12:26:52 2035 GMT Subject: O=example.com Security Domain, CN=CA Signing Certificate # certutil -d /etc/pki/pki-tomcat/alias/ -L -a -n \ 'Server-Cert cert-pki-tomcat' | openssl x509 -text Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: sha256WithRSAEncryption Issuer: O=example.com Security Domain, CN=CA Signing Certificate Validity Not Before: Aug 5 12:26:52 2015 GMT Not After : Jul 25 12:26:52 2017 GMT Subject: O=example.com Security Domain, CN=vm-089.example.com Case #2: new subsystem on the same host --------------------------------------- For new subsystems on the same host, pkispawn simply has to trust the CA Signing Certificate from #1. The same is true for the 389-DS server cert. Case #3: subsystem on different host ------------------------------------ When a new subsystem is installed on a different host, the user must provide the trust anchor for 389-DS out-of-band. A user could also use plain LDAP, but let's not go there. The trust anchor for the LDAP cert might be the same as the trust anchor for the security domain -- or it might be a different one. In both cases it's probably easier to grab the trust anchor from LDAP. The LDAP connection is set up before pkispawn does the first HTTPS request. Case #4: clone on different host -------------------------------- For installations of a clone or subsystem, the trust anchor must be provided out-of-band. For a cloning setup http://pki.fedoraproject.org/wiki/Cloning_Setup the PKCS#12 file should contain all necessary information. It might also be possible to grab the cert from LDAP like in case #3. Case #5: security domain with imported CA ----------------------------------------- I haven't tried to configure a CA with an externally managed and imported trust anchor yet. Does anybody happen to know the nickname of the cert and its trust anchor? Conclusion ========== In case #1 pkispawn should dump the self-signed cert from NSS DB to PEM file. requests can then load the self-signed cert as CA cert. For self-signed certs this makes the cert trusted. The file should be removed at the end of the installation. In case #2 pkispawn should dump the trust anchor from the NSS database to a PEM file, too. I suggest to put the PEM file in a location where it can be read by everybody. /etc/pki/pki-tomcat is only accessible by root and members of the pkiuser group. It has no X bit for other. In case #3 the cert must either be provided out-of-band or grabbed from LDAP. I like the idea to grab it from LDAP and have an official API to do so. Other systems like FreeIPA could use the same API, too. Like in case #2 the cert should be dumped to a public-readable location. We could handle case #2 and #3 the same way and always grab the trust anchor from LDAP. It's less code and more robust, too. Open question ------------- 1) Is there a stable and easy way to find the trust anchor in LDAP? In my test setup the trust anchor has subjectName='CN=CA Signing Certificate,O=example.com Security Domain'. Is the name always similar? 2) Does anybody know how case #5 affects the nickname or subjectName attribute of the trust anchor? Christian