[Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Martin Kosek]

On 05/30/2016 10:53 PM, Prasun Gera wrote:
> 
>     To summarize, your options seem to be:
>     * Create ipa-ca DNS record in your primary domain
>     * Update the main default certificate profile (present in FreeIPA 4.2+)
>     * Migrate whole FreeIPA deployment to other DNS primary you would control
>     (pqr.xyz.com <http://pqr.xyz.com>) - which is a lot of work but may unblock
>     you in future if you
>     want to start the mentioned AD trusts.
> 
>     Martin
> 
> 
> Thanks Martin for the suggestions. In the short term, updating the external will 
> probably not work. Eventually, migration to a domain that I can control will be 
> a better idea, but that will involve a lot more work. Is there any documentation 
> on doing the migration ? My deployment is actually fairly simple right now. We 
> just use it internally for our small lab, mostly as a replacement for NIS. No AD 
> or windows machines. Hence, I didn't bother with a lot of complex dns stuff to 
> begin with. I guess, the only thing we need to preserve is usernames, groups and 
> passwords in the migration.

If you use only users, groups and passwords, the migration may actually not be
that painful as you can migrate with "ipa migrate-ds" command as advised in
http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA
and then enrolling your clients with the new FreeIPA realm. We have a RFE for a
more complete migration tracked
https://fedorahosted.org/freeipa/ticket/3656
that was being worked on as a thesis.

> Regarding your second point, how do I go about updating the cert profile ? Is 
> there any documentation ? If this is not a standard feature, do you think I 
> should open an RFE ?

Certificate Profiles is a standard feature in FreeIPA 4.2+. Profile edit is not
that straightforward, but if you download current one for the profile, you
should be able to figure out what line to edit (and then you just upload the
profile again).

> Also, I'm surprised that nothing broke yet despite the OCSP/CRL stuff not 
> working ever. Isn't this important security-wise? Yet, browsers don't seem to 
> complain by default for https certs once the CA is trusted. Only the java plugin 
> brought this to my attention.

Yeah, browsers generally not care about CRL/OCSP unless explicitly enabled. I
know that at least Firefox has a setting to always check for certificate validity.

> 
> 
>     > On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <rcritten at redhat.com <mailto:rcritten at redhat.com>
>      > <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>>> wrote:
>      >
>      >     Prasun Gera wrote:
>      >
>      >         I've identified the problem. The uris seem to be incorrect. This
>     looks
>      >         like some substitution gone wrong. Instead of using the actual ipa
>      >         server's address, it points to a generic placeholder type text
>      >         (ipa-ca.domain.com <http://ipa-ca.domain.com>
>     <http://ipa-ca.domain.com>
>      >         <http://ipa-ca.domain.com>). Relevant part of the
>      >         certificate:
>      >
>      >
>      >     A generic name is used in case the server that issued the cert goes away.
>      >     Create an entry in DNS for this generic name and things should work
>     as expected.
>      >
>      >     rob
>      >
>      >
>      >         Authority Information Access:
>      >                           OCSP - URI:*http://ipa-ca.domain.com/ca/ocsp*
>      >
>      >                       X509v3 Key Usage: critical
>      >                           Digital Signature, Non Repudiation, Key
>     Encipherment,
>      >         Data Encipherment
>      >                       X509v3 Extended Key Usage:
>      >                           TLS Web Server Authentication, TLS Web Client
>      >         Authentication
>      >                       X509v3 CRL Distribution Points:
>      >
>      >                           Full Name:
>      >                           
>       URI:*http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin*
>      >
>      >
>      >         This is on RHEL 7.2, idm 4.2 btw
>      >
>      >         On Fri, May 27, 2016 at 7:22 PM, Prasun Gera
>     <prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>
>      >         <mailto:prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>>
>     >         <mailto:prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>
>     <mailto:prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>>>> wrote:
>     >
>     >              It looks like that issue was fixed and the OCSP and CRL uris in the
>     >              certs are now http. So I'm not sure why java is complaining.
>     >
>     >              On Fri, May 27, 2016 at 7:03 PM, Prasun Gera <prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>
>     >         <mailto:prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>>
>      >              <mailto:prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>
>     <mailto:prasun.gera at gmail.com <mailto:prasun.gera at gmail.com>>>> wrote:
>      >
>      >                  I've set up a couple of dell idrac card's ssl certs
>     signed by
>      >                  ipa CA. I've also added the ipa CA to java's trusted CAs.
>      >                  However, when you try to launch the idrac java console,
>     it will
>      >                  still show an error that the site is untrusted. Upon
>     clicking on
>      >                  "more information", the message says that although the
>     cert is
>      >                  signed by the CA, it cannot verify the revocation status. I
>      >                  found this page
>      > http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs ,
>      >                  which explains potential problems with this since the
>     main ipa
>      >                  server itself is also using an ssl cert signed by the
>     ipa CA. So
>      >                  the client cannot verify the revocation if it can't
>     reach the
>      >                  CA. Is there any solution to this ? Anyone tried this
>     with idrac
>      >                  cards ?
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
> 
>