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

Wed Apr 3 01:01:54 UTC 2013

On 04/02/2013 02:07 PM, John Dennis wrote:
> 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.
The admin should have told you the CA that can sign the cert. NSS 
doesn't ask the user if a cert is valid, though an application may 
choose to. NSS validates against the installed list of CA's.
>> 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?
The server's cert needs to be signed by a CA that the administrater 
installed on the client as a trusted CA. The rest of the chain is sent 
through the SSL protocol, so you will need the whole chain to validate. 
If you are using NSS for the SSL connection this happens automatically 
unless you take action to handle certificate authentication yourself.
>> 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.

yes, that's the same function NSS calls (by default) when it makes an 
SSL connection. Servers actually use the same function to validate 
client certificates. There's a usage parameter that tells if you are 
validating an SSL_server cert or an SSL client cert (Or an S/MIME or 
Object Signing cert for that matter). The CA is installed by the admin 
with the appropriate flags for what type of cert is expected to 
validate.. this trust can be further narrowed by extensions in any 
intermediate CA between the base CA and the leaf cert you are validating).

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4521 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130402/f959427a/attachment.p7s>