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

Reply via email to