On 05/30/2016 10:53 PM, Prasun Gera wrote: > > 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 <http://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.
If you use only users, groups and passwords, the migration may actually not be that painful as you can migrate with "ipa migrate-ds" command as advised in http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA and then enrolling your clients with the new FreeIPA realm. We have a RFE for a more complete migration tracked https://fedorahosted.org/freeipa/ticket/3656 that was being worked on as a thesis. > 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 ? Certificate Profiles is a standard feature in FreeIPA 4.2+. Profile edit is not that straightforward, but if you download current one for the profile, you should be able to figure out what line to edit (and then you just upload the profile again). > 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. Yeah, browsers generally not care about CRL/OCSP unless explicitly enabled. I know that at least Firefox has a setting to always check for certificate validity. > > > > On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <rcrit...@redhat.com > <mailto:rcrit...@redhat.com> > > <mailto: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> > > <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>> > > <mailto: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>> > > <mailto: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