[Freeipa-devel] [RFE] CA-less install

John Dennis jdennis at redhat.com
Tue Apr 2 21:07:41 UTC 2013


On 04/02/2013 11:33 AM, Petr Viktorin wrote:
> On 04/02/2013 02:14 AM, Robert Relyea wrote:
>> On 03/29/2013 07:40 AM, John Dennis wrote:
>>> On 03/29/2013 07:57 AM, Petr Viktorin wrote:
>>>> On 03/27/2013 04:40 PM, John Dennis wrote:
>>>>> On 03/27/2013 11:23 AM, Petr Viktorin wrote:
>>>>>> I don't want to check the subject because this RFE was prompted by
>>>>>> IPA's
>>>>>> normal CA rejecting valid wildcart certs. Is there a reasonable way to
>>>>>> ask NSS if it will trust the cert?
>>>>>
>>>>> Yes. NSS provides a variety of tools to test validation.
>>>>>
>>>>> Going just on memory here, our current version of python-nss has a
>>>>> simple call to test validation. Sometime in the last year I added a
>>>>> fair
>>>>> amount of new support for certificate validation including getting back
>>>>> diagnostic information for validation failures, however if I recall
>>>>> correctly the extended functionality in python-nss has not been
>>>>> released
>>>>> yet.
>>>>
>>>> Does the new code include downloading and importing CRLs?
>>>
>>> Cert verification is a complex topic. This is further exacerbated by
>>> the introduction of PKIX. My understanding is NSS had "classic"
>>> verification code and later introduced PKIX. There has been an
>>> evolution between classic verification and PKIX. This is outside my
>>> domain of expertise. How and when CRL's are loaded in NSS is not
>>> something I can give advice on, especially in an area undergoing change.
>>>
>>> I'm going to have to defer to an expert in this area, Bob Relyea, I've
>>> CC'ed him on this email.
>> It's hard to get the context in the middle, and and John had noted, NSS
>> is transitioning from the old Cert_Verify interface to the new PKIX_ code.
>>
>> I'll answer the question for the traditional CERTVerify code, which is
>> the only you get in SSL by default, and the one most people still use:
>>
>> No, CRLs are not downloaded and imported automatically, but if you
>> download and import CRL's, NSS will use them. There's an installable
>> PKCS #11 module which can be configured to download and install CRLs,
>> then provide them to NSS. It's call mod_revocator.
>>
>> The expected revocation strategy NSS uses is OCSP, and you can turn on
>> automatic OCSP fetching.
>>
>>> Bob, to put this in context [1] the functionality in python-nss being
>>> discussed is the binding of the CERT_VerifyCertificate() function,
>>> something I added recently. Now the question arises as to how CRL's
>>> are meant to play into the verification process. Can you please
>>> explain how NSS expects this to be done? Pointers to existing
>>> documentation and code examples would also be helpful.
>>
>> There's a separate CERT_ImportCRL() which will import the CRL into the
>> database. mod_revocator() can also be used to do the fetching for you,
>> Matthew has examples on how various servers set them up (I believe the
>> only NSS set up is installing the module in your secmod.db/pkcs11.txt
>> with modutil.
>>
>>>
>>> It would also be helpful to understand the PKIX roadmap and how this
>>> might affect coding decisions at the API level.
>>
>> the PKIX interface is available now, and is actually used by Chrome (for
>> all certs) and Firefox (for ev processing). Firefox is in the process of
>> moving to libpkix for everything.  There is an environment variable you
>> can set (I don't remember it specifically, but I could look it up for
>> you if you want) that will cause the transitional
>> CERT_VerifyCertificate() interface to use the libpkix engine, but it
>> keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert
>> fetching)..
>>
>> With libpkix, the revocation options are quite broad and complexed. We
>> really expect people would use a set of preconfigured policies, though
>> libpkix API allows for quite some variance. It would take me some time
>> to dig up all the descriptions, but I can if you want them.
>>
>>> [1] Some additional context, the original motivation for exposing NSS
>>> cert verification to IPA was to solve the following problem. If
>>> someone wants to make the IPA CA a sub-CA (as opposed to a self-signed
>>> CA) we want to validate the externally provided CA cert *before*
>>> proceeding with the IPA installation. This is because if the CA cert
>>> is invalid everything will hugely blow-up (because we use the CA cert
>>> to sign all the certs issued in IPA, especially those used to validate
>>> cooperating components/agents, if those certs do not work nothing in
>>> IPA works). In addition to this narrow goal we in general want to be
>>> able to perform cert verification correctly in other contexts as well
>>> so the extent to which you can educate us in general on this topic
>>> will be appreciated.
>> OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless
>> you specifically need some of the advanced libpkix features.
>
> The original context is sanity checking: is a SSL server cert we get
> from a user valid? If it is then we install the corresponding server.
> Requirements here are:
> - No extra information from the user, other than the cert itself (the
> admin gives us a cert, we don't want to ask how to find out if it's valid)
> - It needs to be a simple call/tool, since there's little gain over just
> documenting that we want good certs.
> So it looks it's not worth it to go there.
>
>
> The new context, as far as I understand, is cert validation in *clients*.
> We connect to a server; how to find out if its cert is valid?
> In contrast to the sanity checking, we can have complexity and config
> options here. This is important to get right, and we don't want any
> assumptions (other than that everything is under some wacky corporate
> policy).
>
> It looks like libpkix is the way to go here. I assume Python bindings
> aren't available for it yet?

We have python bindings for CERT_VerifyCertificate (I'm pretty sure that 
API has been in the python bindings for a while now). Bob can correct me 
if I'm wrong but I believe that CERT_VerifyCertificate is more than 
adequate for client's which want to validate a certificate, especially 
if the CRL is loaded or OCSP is enabled.

The environment variable Bob is referring to is NSS_ENABLE_PKIX_VERIFY. 
However PKIX verification can also be enabled via the 
CERT_SetUsePKIXForValidation() entry point, which is part of the current 
python-nss bindings (but I don't think that's been released yet, I'd 
have to double check.).

python-nss currently does not have entry points for enabling/disabling 
OCSP checking but it would be trivial to add.




-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the Freeipa-devel mailing list