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

[Martin Kosek]

On 05/28/2016 05:30 AM, Prasun Gera wrote:
> The problem is that I'm not using ipa for dns. dns is handled externally, and I 
> don't have admin access. I have 1 master and 1 replica, and all the clients are 
> enrolled with --server=a,--server=b during installation, and I think it works 
> perfectly fine. Is it possible to instruct ipa to use some alternative for the 
> certs ? If it's not possible to list multiple uris, even just the master would 
> be fine. It would at least work when the master is up, which it doesn't right now.

ipa-ca.$DOMAIN OCSP/CRL is currently hardcoded in the Certificate Profiles, you
would need to edit them with different value (which may then make FreeIPA
upgrades funny).

I still think the easiest solution may be to simply request DNS change in your
external DNS and create the ipa-ca DNS record - it is a simple list of IPA CA
server's IP addresses.

> Secondly, I'm a bit confused regarding the dns too. This error is on a client 
> system like my laptop, which is an entirely unrelated system from the ipa 
> clients. The connection is over the internet. So the dns mapping would have to 
> be visible globally for my laptop to see it. However, the name of the ipa domain 
> is not the same the same as the name of domain in the server addresses. (This 
> was for some historic reason in NIS, and I didn't change the domain name during 
> migration). So what ipa is suggesting is something like ipa-ca.abc.com 
> <http://ipa-ca.abc.com>, whereas all my servers are like server1.pqr.xyz.com 
> <http://server1.pqr.xyz.com>. I don't think it is anyway possible to do this 
> right now since I don't control abc.com <http://abc.com>.

This feature uses the primary FreeIPA DNS domain, which is derived from it's
realm. This is the same approach as with AD. If you do not have access to this
DNS domain, I expect you will have trouble if you want to for example start
using AD Trusts which expects working primary DNS domain with proper SRV
records (FreeIPA servers can still live in other domain though).

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

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