Petr Viktorin wrote:
I'm investigating (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 I suspect that pretty much all the NSS database code in __init__ can go away when selfsign is dropped.


Freeipa-devel mailing list

Reply via email to