On 07/13/2017 09:57 PM, Fraser Tweedale wrote:
OK, I think I understand.
ipa0 has been set up with a 3rd-party HTTP cert, but ipa1 has been
set up with a certificate issued by the IPA CA, which your browser
does not trust.
There are two ways forward here:
1. You can use ipa-server-certinstall to install a 3rd-party (i.e.
not issued by the IPA CA but by a CA trusted by clients - including
browsers - in your organisation) certificate for the HTTP service.
This seems to be how ipa0 is set up so you might want to do that for
consistency.
2. Add the IPA CA certificate to your browser as a trusted CA. If
you need all clients (including users' browsers) in your
organisation to trust certs issued by your FreeIPA CA, then you need
to work out how to push the IPA CA out to all of them, or you need
to chain the IPA CA to a CA that they already trust (e.g.
organisations with Active Directory often chain their IPA CA up to
the AD CA).
Yeah, I got it figured out. For some reason, I expected /all/ the SSL
certs to be carried over when I went through the steps to build the
replica server. All of the /internal/ IPA ones did just fine. It seems
that the wildcard cert that we're using for securing the Web interface
did not (and probably doesn't for anyone else). We have a GoDaddy
signed wildcard SSL cert we use for any web interface (we're HTTPS-only
now). The process to setup the IPA replica didn't include that cert
when I ran 'ipa-replica-install ipa0.gpg'. So, I had to copy the CA
bundle, .crt &.key files and manually install them using
ipa-cacert-manage and ipa-server-certinstall.
I sort of expected the replica to be an identical replica in all
settings, but maybe that was too high an expectation. Regardless, I
have it configured and working properly, so I can move onto putting it
into production.
--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney(a)neonova.net
www.neonova.net