<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
To summarize, your options seem to be:<br>
* Create ipa-ca DNS record in your primary domain<br>
* Update the main default certificate profile (present in FreeIPA 4.2+)<br>
* Migrate whole FreeIPA deployment to other DNS primary you would control<br>
(<a href="http://pqr.xyz.com" rel="noreferrer" target="_blank">pqr.xyz.com</a>) - which is a lot of work but may unblock you in future if you<br>
want to start the mentioned AD trusts.<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br></font></span></blockquote><div><br></div><div>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. </div><div><br></div><div>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 ? </div><div><br></div><div>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. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
</font></span><span class="im HOEnZb"><br>
> On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>>> wrote:<br>
><br>
> Prasun Gera wrote:<br>
><br>
> I've identified the problem. The uris seem to be incorrect. This looks<br>
> like some substitution gone wrong. Instead of using the actual ipa<br>
> server's address, it points to a generic placeholder type text<br>
> (<a href="http://ipa-ca.domain.com" rel="noreferrer" target="_blank">ipa-ca.domain.com</a> <<a href="http://ipa-ca.domain.com" rel="noreferrer" target="_blank">http://ipa-ca.domain.com</a>><br>
> <<a href="http://ipa-ca.domain.com" rel="noreferrer" target="_blank">http://ipa-ca.domain.com</a>>). Relevant part of the<br>
> certificate:<br>
><br>
><br>
> A generic name is used in case the server that issued the cert goes away.<br>
> Create an entry in DNS for this generic name and things should work as expected.<br>
><br>
> rob<br>
><br>
><br>
> Authority Information Access:<br>
> OCSP - URI:*<a href="http://ipa-ca.domain.com/ca/ocsp*" rel="noreferrer" target="_blank">http://ipa-ca.domain.com/ca/ocsp*</a><br>
><br>
> X509v3 Key Usage: critical<br>
> Digital Signature, Non Repudiation, Key Encipherment,<br>
> Data Encipherment<br>
> X509v3 Extended Key Usage:<br>
> TLS Web Server Authentication, TLS Web Client<br>
> Authentication<br>
> X509v3 CRL Distribution Points:<br>
><br>
> Full Name:<br>
> URI:*<a href="http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin*" rel="noreferrer" target="_blank">http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin*</a><br>
><br>
><br>
> This is on RHEL 7.2, idm 4.2 btw<br>
><br>
> On Fri, May 27, 2016 at 7:22 PM, Prasun Gera <<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a><br>
> <mailto:<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>><br>
</div></div><span class="im HOEnZb">> <mailto:<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a> <mailto:<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>>>> wrote:<br>
><br>
> It looks like that issue was fixed and the OCSP and CRL uris in the<br>
> certs are now http. So I'm not sure why java is complaining.<br>
><br>
> On Fri, May 27, 2016 at 7:03 PM, Prasun Gera <<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a><br>
> <mailto:<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a> <mailto:<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>>>> wrote:<br>
><br>
> I've set up a couple of dell idrac card's ssl certs signed by<br>
> ipa CA. I've also added the ipa CA to java's trusted CAs.<br>
> However, when you try to launch the idrac java console, it will<br>
> still show an error that the site is untrusted. Upon clicking on<br>
> "more information", the message says that although the cert is<br>
> signed by the CA, it cannot verify the revocation status. I<br>
> found this page<br>
> <a href="http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs" rel="noreferrer" target="_blank">http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs</a> ,<br>
> which explains potential problems with this since the main ipa<br>
> server itself is also using an ssl cert signed by the ipa CA. So<br>
> the client cannot verify the revocation if it can't reach the<br>
> CA. Is there any solution to this ? Anyone tried this with idrac<br>
> cards ?<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>