On 03/18/2013 10:24 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
From what I've learned, PKCS#12 files are just a bag of certificates;
there are basically no restrictions on their contents. But we assume
there's only one cert inside that has a private key, and use that for
the server cert. We also pretty much assume that there's one CA cert: if
not we pick the first one and trust it as root CA.
In short, I think --http_pkcs & friends are too vague for PKCS#12s we
don't control; we should have the user name the certs more explicitly.
Am I wrong here? Is this the usual way to import server certs?
We can impose a requirement that the CA be included in the PKCS#12
files. At least with NSS this happens automatically, I can't recall with
Or we can add a new option to pass in the CA bundle in PEM format.
After thinking about it, this is the way I want to go. It's a bit more
typing for the user, but it reduces the amount of guesswork the
installer needs to do. When deciding who to trust I'd rather be explicit.
There's also a bit less validation to do and corner cases to watch out for.
The root CA certificate will be given by --external-ca-file. The trust
chains for both servers (dirsrv, http) must lead to that CA. This CA
will be trusted, and put in /etc/ipa/ca.crt.
Each PKCS#12 file must contain exactly one cert with a private key. This
cert will be used for the corresponding server.
Of course you can use the same cert for both servers.
The --external_ca_file must contain exactly one cert. Certs for any
intermediate CAs must be in the PKCS#12.
Does that look good? Does it need a design page?
I have some patches for this and for replication, but it'll take another
day to polish and test them.
I'm not sure the dogtag 9 removal code really fits in the context of
these changes. It makes sense, but has nothing to do with this.
I'll retire that patch for now.
Freeipa-devel mailing list