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.

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, whereas all my servers are like
server1.pqr.xyz.com. I don't think it is anyway possible to do this right
now since I don't control abc.com.


On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <rcrit...@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>). 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.g...@gmail.com
>> <mailto:prasun.g...@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.g...@gmail.com
>>     <mailto:prasun.g...@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 ?
>>
>>
>>
>>
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to