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

[Prasun Gera]

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

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 ?

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.



>
> > On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <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>). 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>>>
> 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>>>
> 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 ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160530/26dfbaa8/attachment.htm>