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

[Petr Viktorin]

On 03/18/2013 10:24 PM, Rob Crittenden wrote:
> 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.

I think most tools will at least give you the option to export the whole 
trust chain.

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

I guess we could reuse --external_ca_file for it.

> 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.

The real problem here is that since the order is not guaranteed, if 
there is more than one CA it might end up picking the wrong one to give 
root trust to. Receiving the CA cert explicitly would solve the issue.

> 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.

Even for case #1 we still need to put something in /etc/ipa/ca.crt. I 
guess in this case it would be the globally trusted root cert?

> 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.

I'll keep it in mind.
In my patch I mostly operate with nssdb names, because when the certs 
are imported I can check the flags.

> 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.

AFAIK, "u" just means that we have the corresponding private key, so in 
this case you should get an error about CAs 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.

I had that patch almost ready. When I was doing the certs and some 
Dogtag 9 code got in my way I just took the patch, cleaned it up and 
included it. So yes, it touches a more than certs.
Should I make a separate review thread for it?

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

Will do.

-- 
Petr³