[Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs

[Rob Crittenden]

Petr Viktorin wrote:
> Hello,
> While the work is not complete, these patches allowed me to install an
> IPA server without a CA, using PKCS#12 files for the server certs.
>
> The patches don't break normal installation.
> The --selfsign option (but not yet the code behind it) is removed.
>
> The absence of a CA is indicated by `enable_ra=False` in the IPA config.
>
> ipa-replica-install will still refuse to run; I'll look into that next.
>
> I removed some unused code that got in my way: Dogtag 9 installation (we
> can run a Dogtag 9-style CA, but we never *install* it), and
> ipapython.certdb.CertDB (unused, not to be confused with ipaserver's
> CertDB).
>
> I tried using python-nss, but unfortunately found that it's not yet
> usable here. John filed
> https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our
> conversation. Parsing certutil output, while dirty, is more reliable in
> my limited experience.
> I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper
> around certdb operations. We have a CertDB class for it but that one is
> too tied to the current code paths: when I used it I found myself
> re-implementing a lot of methods to get rid of some assumption or other.
> The new NSSDatabase is not tied to IPA configuration.
>
>
>  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 
openssl.

Or we can add a new option to pass in the CA bundle in PEM format.

I'm not sure that order is guaranteed so I'm not sure your comparison 
that the DS and HTTP certs are signed by the same issuer will be true. 
In any case it may not matter, as long as they are trusted. It does 
raise the issue of what CA to put into /etc/ipa and LDAP but if it is an 
existing root cert there should be no issues.

So there are really 2 use cases here:

- They got certs from an upstream CA like Verisign, Thawte, etc.
- They got certs from an internal CA.

For case #1 there is probably nothing to do as the CAs are likely 
already trusted by the world. The second case needs to be handled more 
carefully.

There was a time, and it still may be the case, where we loosely handled 
the format of certificates. In some cases it was PEM, in others it was 
DER, and the only way you'd know is if you coded it or happened to look 
at the contents of the variable.

We decided on trying to keep all certs internally in DER format, at 
least for the framework CA code. We typically use the variable dercert 
in that case. I didn't notice any inconsistencies, just something for 
you to be aware of.

For find_server_certs() I wonder what happens if you pass in a PKCS#12 
file with no CA's. It may not set any u flags if the cert comes from an 
unknown issuer, so we would report no server certificates found, but the 
real problem is no CA's found.

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.

You can probably simplify the imports of certdb.py along with the code 
removal.

rob