[Freeipa-devel] Custom SSL certificates

[Rob Crittenden]

Petr Viktorin wrote:
> Hi,
> I'm investigating https://fedorahosted.org/freeipa/ticket/3363 (fix
> --http_pkcs12 & friends).
> I can't find documentation on these options, and from the code I can't
> figure out enough about how they are/were supposed to work.
> Is it the case that they were last used/tested before IPA started using
> Dogtag, and have rotted since then?
>
> Custom certs don't make sense to use if Dogtag is installed, right? So
> when they're provided we should not install the CA and Certmonger?
> If that's the case it would be easier (development- and testing-wise) to
> just remove self-signed CA in the same set of patches.
>

I lack a little context about what was discussed on Tuesday but yeah, 
that sounds about right. We probably only want this if we don't have a 
real CA (including selfsign) behind IPA and I'm fine with dropping 
selfsign if we provide a no-CA option.

These options come from V1 where many people didn't like our extremely 
limited selfsign CA and wanted to be able to provide their own certs.

The bit-rot is a bit limited I think because a bunch of this code is 
still used, when installing replicas for example. The problem is that 
there are a lot of corner cases that we don't exercise because the certs 
we use are all of one predictable form.

John added some PKCS#12 support to python-nss which should make some of 
this handling a lot cleaner. IIRC right now we handle everything using 
certutil which is very limiting.

We also still tend to stomp on everything we see, and in V1 it was even 
more so, hence our overwriting NSS database files at will.

As for how they should work...

We need to stand up two SSL services, HTTP and LDAP. So we provide 
options for the use to present two PKCS#12 files (they can be the same) 
and the pins for those files.

We need to:
- load the PKCS#12 files into an NSS database
- determine what the nickname of the server cert is so we can configure 
things
- determine what the nickname of the CA is so we can publish *something* 
in /etc/ipa/ca.crt, and get the trust right

I believe the assumption is that the same CA is used for both SSL and 
HTTP, though from a technical perspective this doesn't need to be true.

And you're right, no certmonger here.

There also needs to be some way to enforce that the user provide certs 
when running ipa-replica-prepare.

What I'd propose is a new value for ra_plugin to indicate user-provided 
certs. I don't know if a new subclass would be desired or not, but it 
might be nice to provide a specific message rather than 'not 
implemented' for all cert commands.

Be aware that a little bit of selfsign-specific code made it into the 
parent class in rabase.py. I suspect that pretty much all the NSS 
database code in __init__ can go away when selfsign is dropped.

rob