[Pki-devel] PKIConnection cert validation #1253

[Fraser Tweedale]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel