6:16 a.m.
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