10:11 a.m.
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