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
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
On 2015-08-05 18:53, Endi Sukma Dewata wrote:
I'm not fully familiar with the process, but I have some comments below.
Thanks :)
I suppose if LDAPS is required, the DS trust anchor would have to be provided before running pkispawn.
Correct, pkispawn even asks for the trust anchor. By the way the X.509 cert for LDAPS may not necessarily have the same trust anchor as the PKI security domain.
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.
Good catch! IMO we can treat the case like 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.
Yes, LDAPS or StartTLS for LDAP are optional. Let's work under the basic requirement that the LDAP connection is properly secured. It's a different topic.
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.
LDAPS implies that we already have *a* trust anchor *somewhere*. But it doesn't mean that we have the trust anchor for PKI RPC calls over HTTPS. For example the DS server might use a certificate that is signed by a public root CA or some other CA that is already in the system cert.
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.
Yes, that's exactly my idea, too. Do you have a suggestion for a directory? We should also consider the case of multiple independent PKIs on the same host. I'm not sure how to solve the issue. Perhaps we can store the trust anchor as pki-$NAME.pem and maintain a combined file with all trust anchors? The trust anchor should also be removed by pkidestroy.
If the subsystem is installed on the same host, the trust anchors should already be available in the default location.
Right!
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.
I'm not very familiar with the setup. But I think a PKCS#12 is only involved for clones. For an external subsystem like a OCSP on a different host, a PKCS #12 file is not involved. During my test setup I only had to specify the DS and Security Domain hosts and credentials.
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.
see above
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
#1473 has one flaw: A remote procedure call suffers from the chicken and egg dilemma. The trust anchor is required to make an authenticated RPC. Christian
On Thu, Aug 06, 2015 at 01:16:49PM +0200, Christian Heimes wrote:
On 2015-08-05 18:53, Endi Sukma Dewata wrote:
I'm not fully familiar with the process, but I have some comments below.
Thanks :)
I suppose if LDAPS is required, the DS trust anchor would have to be provided before running pkispawn.
Correct, pkispawn even asks for the trust anchor. By the way the X.509 cert for LDAPS may not necessarily have the same trust anchor as the PKI security domain.
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.
Good catch! IMO we can treat the case like 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.
Yes, LDAPS or StartTLS for LDAP are optional. Let's work under the basic requirement that the LDAP connection is properly secured. It's a different topic.
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.
LDAPS implies that we already have *a* trust anchor *somewhere*. But it doesn't mean that we have the trust anchor for PKI RPC calls over HTTPS. For example the DS server might use a certificate that is signed by a public root CA or some other CA that is already in the system cert.
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.
Yes, that's exactly my idea, too. Do you have a suggestion for a directory?
On Fedora and RHEL the "official" way is to put the PEM file in /etc/pki/ca-trust/source/ then run update-ca-trust(8). (Unlink and update-ca-trust to remove the trust anchor.)
We should also consider the case of multiple independent PKIs on the same host. I'm not sure how to solve the issue. Perhaps we can store the trust anchor as pki-$NAME.pem and maintain a combined file with all trust anchors?
I agree with using the instance name in the filename. Simple and makes it obvious where the file came from.
The trust anchor should also be removed by pkidestroy.
If the subsystem is installed on the same host, the trust anchors should already be available in the default location.
Right!
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.
I'm not very familiar with the setup. But I think a PKCS#12 is only involved for clones. For an external subsystem like a OCSP on a different host, a PKCS #12 file is not involved. During my test setup I only had to specify the DS and Security Domain hosts and credentials.
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.
see above
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
#1473 has one flaw: A remote procedure call suffers from the chicken and egg dilemma. The trust anchor is required to make an authenticated RPC.
Christian
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
participants (3)
-
Christian Heimes -
Endi Sukma Dewata -
Fraser Tweedale