Petr Viktorin wrote:
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
- 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.
Freeipa-devel mailing list