On Fri, Jul 14, 2017 at 07:47:39AM -0400, Mark Haney via FreeIPA-users wrote:
> 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
> 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
Glad you've figured it out.
In general, there must be different certs on a replica because the
hostname is different. IPA does not do the work to figure out that
the wildcard cert on the master will be valid for the replica too
and therefore use it for the replica services - and it almost
certainly never will (wildcard certs are deprecated).
But, during ipa-replica-intsall(1) you can provide certificates for
the Directory Server and Apache HTTPD via the --dirsrv-cert-file and
--http-cert-file options. This way you can give the replica the
wildcard certs from the start, and it will not issue certs from the
IPA CA for these services. This would have achieved the desired
FreeIPA-users mailing list -- firstname.lastname@example.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org