Automated Certificate Management Environment (ACME) SRV Identifier Validation Extension

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 February 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Many application protocols can use DNS SRV records [RFC2782] for service discovery and delegation to third-party hosting providers. Organizations often wish to maintain their domain identity (e.g., example.com) while delegating the actual service hosting to specialized providers.¶

Currently, obtaining proper PKIX certificates for such delegated services presents significant operational challenges. The hosting provider cannot easily obtain certificates for the customer's domain without either:¶

• Access to the customer's DNS infrastructure for validation¶

• Access to the customer's web server for HTTP validation¶

• The customer obtaining certificates and sharing private keys¶

These approaches are either operationally infeasible, introduce security risks, or do not scale effectively in multi-tenant environments.¶

This document extends ACME [RFC8555] to support SRV-ID identifiers [RFC4985], enabling hosting providers to obtain certificates that properly identify delegated services without requiring control over the source domain's infrastructure.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the following terms:¶

Source Domain:

The domain that owns the service identity (e.g., example.com in _myservice.example.com)¶

Target Domain:

The domain providing the actual service hosting (e.g., hosting.example.net)¶

SRV-ID:

An identifier type defined in [RFC4985] representing a service-specific identity¶

3. Problem Statement

Consider an organization using example.com that wishes to delegate multiple services to different providers:¶

• Service A to provider-a.example¶

• Service B to provider-b.example¶

• Service C to provider-c.example¶

These services might be discovered via SRV records such as:¶

_service-a._tcp.example.com. 86400 IN SRV 0 5 5001 provider-a.example.
_service-b._tcp.example.com. 86400 IN SRV 0 5 5002 provider-b.example.
_service-c._tcp.example.com. 86400 IN SRV 0 5 5003 provider-c.example.

Without DNSSEC (which has limited deployment), these delegations are vulnerable to DNS spoofing attacks. Current ACME validation methods cannot be used by the hosting providers to obtain certificates for example.com without coordination that is often impractical.¶

Existing approaches have significant limitations:¶

• DANE [RFC6698]: Requires DNSSEC deployment, which remains limited across many TLDs and registrars¶

• POSH [RFC7711]: Requires placing files in .well-known on the source domain's web server. If that web server is compromised (e.g., through a CMS vulnerability), an attacker could modify the POSH files¶

• dns-account-01 [I-D.ietf-acme-dns-account-label]: While this challenge type allows multiple providers to independently validate the same domain through unique DNS labels, it ties the validation to a specific ACME account URL that includes the CA endpoint. This creates operational inflexibility: if a hosting provider needs to switch CAs (due to rate limits, outages, pricing changes, or other operational reasons), every customer would need to update their DNS records to reflect the new account URL. This requirement is impractical at scale and effectively locks providers into a single CA¶

• Certificate sharing: Requires distributing private keys between organizations, creating security and operational concerns¶

4. SRV Identifier Type

This document defines a new ACME identifier type "srv" for use in authorization objects.¶

An SRV identifier object has the following fields:¶

type (required, string):

The string "srv"¶

value (required, string):

The SRVName as defined in [RFC4985], in the format "_service.domain". MUST begin with an underscore followed by the service name, then a dot, then the domain name. This format corresponds to the SRVName structure in [RFC4985] Section 2, which omits the protocol component found in DNS SRV records.¶

Example identifier object:¶

{
  "type": "srv",
  "value": "_myservice.example.com"
}

5. Identifier Validation Challenges

SRV identifiers MUST be validated using the dns-01 challenge type as defined in [RFC8555] Section 8.4, with the following modification:¶

When validating an SRV identifier, the challenge TXT record MUST be provisioned under the service name rather than the base domain. Specifically:¶

1. The client constructs the validation domain name by prepending "_acme-challenge." to the SRV identifier value.¶

2. For an SRV identifier "_myservice.example.com", the resulting validation domain would be: "_acme-challenge._myservice.example.com"¶

3. The client provisions a TXT record at this location containing the base64url encoding of the SHA-256 digest of the key authorization, as specified in the standard dns-01 challenge.¶

The server performs validation by:¶

1. Computing the SHA-256 digest of the stored key authorization¶

2. Querying for TXT records at the validation domain name constructed from the SRV identifier¶

3. Verifying that the contents of one of the TXT records matches the digest value¶

HTTP-01 and other challenge types MUST NOT be used for SRV identifier validation, as they cannot properly demonstrate control of a service-specific identifier.¶

6. Validation Process

The validation flow is:¶

1. Client creates a newOrder request with an SRV identifier¶

2. Server creates authorization with dns-01 challenge¶

3. Client provisions DNS TXT record at the service-specific location¶

4. Server validates the dns-01 challenge¶

5. Upon successful validation, server issues certificate containing the SRV-ID from the original identifier value¶

The issued certificate MUST contain the SRV-ID in the subjectAltName extension as specified in [RFC4985], using the id-on-dnsSRV form.¶

The issued certificate MUST NOT include a Common Name (CN) in the subject field. Placing a SRVName in the CN field could lead to interpretation issues with software interpreting the SRVName in the CN field as a standard domain name.¶

7. Security Considerations

8. IANA Considerations

9. References

Acknowledgments

Author's Address