[Pki-devel] PKIConnection cert validation #1253
Endi Sukma Dewata
edewata at redhat.com
Wed Aug 5 16:53:45 UTC 2015
On 8/5/2015 10:11 AM, Christian Heimes wrote:
> 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.
I hope you enjoyed the view :)
> Ade already
> pointed three distinct cases. There might be a couple more case, though.
> I haven't tried them all yet.
I'm not fully familiar with the process, but I have some comments below.
> 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
I suppose if LDAPS is required, the DS trust anchor would have to be
provided before running pkispawn.
> 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.
If the new subsystem is in the same instance as the CA, they will share
the same NSS database, so I suppose there's no additional steps required
to trust the CA/DS certs.
If the new subsystem is in a different instance, it will require
exporting into PKCS #12 file as in case #3.
> 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.
And some other CA certs too.
> A user could also use
> plain LDAP, but let's not go there.
To my understanding LDAPS is optional. The DS might be local and secured
in some ways that a plain LDAP connection is acceptable.
> 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.
Do you want to get the trust anchors with LDAPS or a plain LDAP? If
LDAPS, doesn't it mean you need to have the trust anchors already?
Since we will be transporting some CA certs & keys via PKCS #12 anyway,
we might as well include the DS trust anchor there.
> 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.
I think this is identical to 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?
Not sure, but I think an external CA cert can be included in the same
PKCS #12 file.
> 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.
Right. Additionally, at the end of installation we probably should
export the trust anchors into PEM and store it at a standard location
(e.g. SSL_CERT_DIR) so all applications can use it immediately.
> 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.
If the subsystem is installed on the same host, the trust anchors should
already be available in the default location.
> 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.
If the subsystem is installed on a different host, the trust anchors
should be exported from the PKCS #12 into the standard location on that
host.
> 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.
As mentioned above, since we'll be transporting PKCS #12 file anyway,
I'm not sure if we should/can use LDAP.
> 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?
I'm not sure if that is guaranteed. A better way would be to retrieve
the actual cert used by the subsystem by its tag/nickname:
https://fedorahosted.org/pki/ticket/1473
> 2) Does anybody know how case #5 affects the nickname or subjectName
> attribute of the trust anchor?
Not very familiar with this case.
> Christian
--
Endi S. Dewata
More information about the Pki-devel
mailing list