5. Security Considerations

5. Security Considerations

The design of this challenge relies on some assumptions centered around how an HTTPS server behaves during validation.

The first assumption is that when an HTTPS server is being used to serve content for multiple DNS names from a single IP address, it properly segregates control of those names to the users that own them. This means that if User A registers Host A and User B registers Host B, the HTTPS server should not allow a TLS request using an SNI value for Host A to be served by User B or a TLS connection with a server_name extension identifying Host B to be answered by User A. If the HTTPS server allows User B to serve this request, it allows them to illegitimately validate control of Host A to the ACME server.

The second assumption is that a server will not violate [RFC7301] by blindly agreeing to use the acme-tls/1 protocol without actually understanding it.

To further mitigate the risk of users claiming domain names used by other users on the same infrastructure hosting providers, CDNs, and other service providers SHOULD NOT allow users to provide their own certificates for the TLS ALPN validation process. If providers wish to implement TLS ALPN validation, they SHOULD only generate certificates used for validation themselves and not expose this functionality to users.

The extensions to the ACME protocol described in this document build upon the Security Considerations and threat model defined in Section 10.1 of [RFC8555].