On Mon, Jul 17, 2017 at 08:48:36AM -0400, Mark Haney wrote:
On 07/16/2017 09:47 PM, Fraser Tweedale wrote:
>
> 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
> outcome.
>
> Cheers,
> Fraser
That's good info to have, but I keep hearing that wildcard certs are
deprecated/going away, but I've seen nothing from any sources (outside of
mailing lists) that back that up. I'm curious as to why that is (I know why
wildcards are considered bad), but why I've not seen anything remotely
official on it.
https://tools.ietf.org/html/rfc6125#section-7.2
This document states that the wildcard character '*' SHOULD NOT
be included in presented identifiers but MAY be checked by
application clients (mainly for the sake of backward
compatibility with deployed infrastructure).
Furthermore, note that wildcards in dNSName values (SAN), although
supported by most clients, are technically a violation of RFC 5280.
The deprecation (and now, actual removal in clients) of CN-based
validation poses another challenge in this regard.
Some years ago it seemed impossible that CN-based hostname
validation, despite being officialy deprecated in RFC 2818 and the
deprecation affirmed by RFC 6125, would ever happen. But it has
happened. The thing is... "all the clients still support it"...
until they don't anymore!
Cheers,
Fraser