freeipa/ipalib
Fraser Tweedale 4cf9c8689f httpinstance: add fqdn and ipa-ca alias to Certmonger request
BACKGROUND:

We are implementing ACME support in FreeIPA (umbrella ticket:
https://pagure.io/freeipa/issue/4751).  ACME is defined in RFC 8555.
HTTPS is REQUIRED (https://tools.ietf.org/html/rfc8555#section-6.1).
Therefore, every FreeIPA server that provides the ACME service
capability must be reachable by HTTPS.

RFC 8555 does not say anything about which port to use for ACME.
The default HTTPS port of 443 is implied.  Therefore, the FreeIPA
ACME service will be reached via the Apache httpd server, which will
be the TLS server endpoint.

As a usability affordance for ACME clients, and as a maintainability
consideration i.e. to allow the topology to change without having to
reconfigure ACME clients, there should be a a single DNS name used
to reach the IPA ACME service.

The question then, is which DNS name to use.

REQUIREMENTS:

Each FreeIPA server that is also an ACME server must:

1. Be reachable via a common DNS name

2. Have an HTTP service certificate with that DNS name as a SAN
   dNSName value

DESIGN CONSIDERATION - WHAT DNS NAME TO USE?:

Some unrelated FreeIPA ACME design decisions provide important
context for the DNS name decision:

- The ACME service will be automatically and unconditionally
  deployed (but not necessarily *enabled*) on all CA servers.

- Enabling or disabling the ACME service will have topology-wide
  effect, i.e. the ACME service is either enabled on all CA
  servers, or disabled on all CA servers.

In a CA-ful FreeIPA deployment there is already a DNS name that
resolves to all CA servers: ``ipa-ca.$DOMAIN``, e.g.
``ipa-ca.example.com``.  It is expected to point to all CA servers
in the deployment, and *only* to CA servers.  If internal DNS is
deployed, the DNS records for ``ipa-ca.$DOMAIN`` are created and
updated automatically.  If internal DNS is not deployed,
administrators are required to maintain these DNS records
themselves.

The ``ipa-ca.$DOMAIN`` alias is currently used for OCSP and CRL
access.  TLS is not required for these applications (and it can
actually be problematic for OCSP).  Enabling TLS for this name
presents some risk of confusion for operators.  For example, if they
see that TLS is available and alter the certificate profiles to
include an HTTPS OCSP URL in the Authority Information Access (AIA)
extension, OCSP-using clients may fail to validate such
certificates.  But it is possible for administrators to make such a
change to the profile, whether or not HTTPS is available.

One big advantage to using the ``ipa-ca.$DOMAIN`` DNS name is that
there are no new DNS records to manage, either in the FreeIPA
implementation or for administrators in external DNS systems.

The alternative approach is to define a new DNS name, e.g.
``ipa-acme.$DOMAIN``, that ACME clients would use.  For internal
DNS, this means the FreeIPA implementation must manage the DNS
records.  This is straightforward; whenever we add or remove an
``ipa-ca.$DOMAIN`` record, also add/remove the ``ipa-acme.$DOMAIN``
record.  But for CA-ful deployments using external DNS, it is
additional work for adminstrators and, unless automated, additional
room for error.

An advantage of using a different DNS name is ``ipa-ca.$DOMAIN`` can
remain inaccessible over HTTPS.  This possibly reduces the risk of
administrator confusion or creation of invalid AIA configuration in
certificate profiles.

Weighing up the advantages and disadvantages, I decided to use the
``ipa-ca.$DOMAIN`` DNS name.

DESIGN CONSIDERATION - CA SERVERS, OR ALL SERVERS?:

A separate decision from which name to use is whether to include it
on the HTTP service certificate for ACME servers (i.e. CA servers)
only, or on all IPA servers.

Combined with the assumption that the chosen DNS name points to CA
servers *only*, there does not seem to be any harm in adding it to
the certificates on all IPA servers.

The alternative is to only include the chosen DNS name on the HTTP
service certificates of CA servers.  This approach entails some
additional complexity:

- If a non-CA replica gets promoted to CA replica (i.e. via
  ``ipa-ca-install``), its HTTP certificate must be re-issued with
  the relevant name.

- ipa-server-upgrade code must consider whether the server is a CA
  replica when validating (and if necessary re-creating) Certmonger
  tracking requests

- IPA Health Check must be made aware of this factor when checking
  certificates and Certmonger tracking requests.

Weighing up the options, I decided to add the common DNS name to the
HTTP service certificate on all IPA servers.  This avoids the
implementation complexity discussed above.

CHANGES IN THIS COMMIT

When (re-)tracking the HTTP certificate, explicitly add the server
FQDN and ipa-ca.$DOMAIN DNS names to the Certmonger tracking request.

Related changes follow in subsequent commits.

Part of: https://pagure.io/freeipa/issue/8186

Reviewed-By: Rob Crittenden <rcritten@redhat.com>
2020-03-25 11:13:03 +11:00
..
install httpinstance: add fqdn and ipa-ca alias to Certmonger request 2020-03-25 11:13:03 +11:00
__init__.py pylint: Clean up comment 2020-02-12 18:08:32 +02:00
aci.py Py3: Replace six.string_types with str 2018-09-27 16:11:18 +02:00
backend.py Fix Pylint 2.0 violations 2018-07-14 12:04:19 +02:00
base.py Py3: Replace six.string_types with str 2018-09-27 16:11:18 +02:00
capabilities.py Replace LooseVersion 2016-11-24 15:46:40 +01:00
cli.py make sure IPA_CONFDIR is used to check that client is configured 2019-01-10 11:24:08 +01:00
config.py Don't hard-code client's TLS versions and ciphers 2019-12-02 16:48:07 +01:00
constants.py Do not renew externally-signed CA as self-signed 2020-01-29 21:47:14 +11:00
crud.py ipalib, ipaserver: fix incorrect API.register calls in docstrings 2016-05-25 16:06:26 +02:00
dns.py dnsrecord-mod: allow to modify ttl without passing the record 2019-07-01 09:16:21 +02:00
errors.py Require UTF-8 fs encoding 2017-11-21 16:13:28 +01:00
frontend.py Fixed errors newly exposed by pylint 2.4.0 2019-09-25 20:14:06 +10:00
krb_utils.py Allow login to WebUI using Kerberos aliases/enterprise principals 2017-03-08 15:56:11 +01:00
Makefile.am Build: Makefiles for Python packages 2016-11-09 13:08:32 +01:00
messages.py Handle missing LWCA certificate or chain 2019-06-18 10:36:24 +10:00
misc.py Add fix for ipa plugins command 2017-02-17 10:22:07 +01:00
output.py Generate same API.txt under Python 2 and 3 2018-02-15 09:41:30 +01:00
parameters.py DNParam: raise Exception when multiple values provided to a 1-val param 2019-11-20 11:15:28 +01:00
pkcs10.py Remove pkcs10 module contents 2017-10-25 09:46:41 +02:00
plugable.py Removed unnecessary imports after code review. 2019-09-27 09:38:32 +02:00
request.py Py3: Remove subclassing from object 2018-09-27 11:49:04 +02:00
rpc.py rpc: always read response 2018-11-07 08:39:42 +01:00
setup.cfg Port all setup.py to setuptools 2016-10-20 18:43:37 +02:00
setup.py Cleanup shebang and executable bit 2018-07-05 19:46:42 +02:00
text.py Py3: Remove subclassing from object 2018-09-27 11:49:04 +02:00
util.py Fix logic of check_client_configuration 2019-12-05 15:09:38 +01:00
x509.py move MSCSTemplate classes to ipalib 2019-07-17 17:58:58 +03:00