mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
4cf9c8689f
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> |
||
|---|---|---|
| .copr | ||
| asn1 | ||
| client | ||
| contrib | ||
| daemons | ||
| doc | ||
| init | ||
| install | ||
| ipaclient | ||
| ipalib | ||
| ipaplatform | ||
| ipapython | ||
| ipaserver | ||
| ipatests | ||
| po | ||
| pypi | ||
| selinux | ||
| util | ||
| .freeipa-pr-ci.yaml | ||
| .git-commit-template | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mailmap | ||
| .tox-install.sh | ||
| .wheelconstraints.in | ||
| ACI.txt | ||
| API.txt | ||
| app.py | ||
| autogen.sh | ||
| BUILD.txt | ||
| CODE_OF_CONDUCT.md | ||
| configure.ac | ||
| Contributors.txt | ||
| COPYING | ||
| COPYING.openssl | ||
| freeipa.doap.rdf | ||
| freeipa.spec.in | ||
| ipa.in | ||
| ipa.sh | ||
| ipasetup.py.in | ||
| make-doc | ||
| make-test | ||
| makeaci.in | ||
| makeapi.in | ||
| Makefile.am | ||
| Makefile.python.am | ||
| Makefile.pythonscripts.am | ||
| makerpms.sh | ||
| pylint_plugins.py | ||
| pylintrc | ||
| README.facilitators | ||
| README.md | ||
| server.m4 | ||
| tox.ini | ||
| Vagrantfile | ||
| VERSION.m4 | ||
| zanata.xml | ||
FreeIPA Server
FreeIPA allows Linux administrators to centrally manage identity, authentication and access control aspects of Linux and UNIX systems by providing simple to install and use command line and web based management tools.
FreeIPA is built on top of well known Open Source components and standard protocols with a very strong focus on ease of management and automation of installation and configuration tasks.
FreeIPA can seamlessly integrate into an Active Directory environment via cross-realm Kerberos trust or user synchronization.
Benefits
FreeIPA:
- Allows all your users to access all the machines with the same credentials and security settings
- Allows users to access personal files transparently from any machine in an authenticated and secure way
- Uses an advanced grouping mechanism to restrict network access to services and files only to specific users
- Allows central management of security mechanisms like passwords, SSH Public Keys, SUDO rules, Keytabs, Access Control Rules
- Enables delegation of selected administrative tasks to other power users
- Integrates into Active Directory environments
Components
The FreeIPA project provides unified installation and management tools for the following components:
- LDAP Server - based on the 389 project
- KDC - based on MIT Kerberos implementation
- PKI based on Dogtag project
- Samba libraries for Active Directory integration
- DNS Server based on BIND and the Bind-DynDB-LDAP plugin
Project Website
Releases, announcements and other information can be found on the IPA server project page at http://www.freeipa.org/ .
Documentation
The most up-to-date documentation can be found at http://freeipa.org/page/Documentation .
Quick Start
To get started quickly, start here: http://www.freeipa.org/page/Quick_Start_Guide
For developers
- Building FreeIPA from source
- http://www.freeipa.org/page/Build
- See the BUILD.txt file in the source root directory
Licensing
Please see the file called COPYING.
Contacts
- If you want to be informed about new code releases, bug fixes, security fixes, general news and information about the IPA server subscribe to the freeipa-announce mailing list at https://www.redhat.com/mailman/listinfo/freeipa-interest/ .
- If you have a bug report please submit it at: https://pagure.io/freeipa/issues
- If you want to participate in actively developing IPA please subscribe to the freeipa-devel mailing list at https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/ or join us in IRC at irc://irc.freenode.net/freeipa