> > > 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 <rcrit...@redhat.com > > <mailto: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> > > <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> > > <mailto: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> > > <mailto: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