Summary
The Let’s Encrypt staging and production ACME APIs now support RFC 8555 “Subproblems”, allowing more than one error to be returned in contexts where multiple identifiers are involved.
We encourage ACME client developers to add support for parsing and displaying these subproblems to end users. For more information see RFC 8555 Section 6.7.1.
Background
In some cases during an ACME issuance flow multiple identifiers are provided by the client in a request and the server may have error information to return to the client related to one or more of the identifiers.
One simple example is when a newOrder request for a set of identifiers includes malformed or policy forbidden identifiers. For example, this newOrder request with one valid identifier and two invalid identifiers (one for a domain under an invalid TLD and one for a domain with an invalid character):
{
"identifiers": [
{
"value": "letsencrypt.org",
"type": "dns"
},
{
"value": "invalid!",
"type": "dns"
},
{
"value": "invalid.notatld",
"type": "dns"
}
]
}
Previously when receiving a request like this Boulder would return an error message that either indicated only one of the problematic identifiers, or that had a detail message that concatenated several independent errors in a way that is difficult to reliably parse and not specified in RFC 8555.
With Subproblem support Boulder will now return a composite problem with subproblems as described in RFC 8555
{
"type": "urn:ietf:params:acme:error:rejectedIdentifier",
"detail": "Error creating new order :: Cannot issue for \"invalid!\": Invalid character in DNS name (and 1 more problems. Refer to sub-problems for more information.)",
"status": 400,
"subproblems": [
{
"type": "malformed",
"detail": "Error creating new order :: Invalid character in DNS name",
"status": 400,
"Identifier": {
"type": "dns",
"value": "invalid!"
}
},
{
"type": "malformed",
"detail": "Error creating new order :: Name does not end in a public suffix",
"status": 400,
"Identifier": {
"type": "dns",
"value": "invalid.notatld"
}
}
]
}
Presently we return subproblems for some invalid newOrder requests and for some invalid Order finalize requests. If you find other error messages/situations that would benefit from subproblems please let us know!
Special thanks to community member and ACME client developer @rmbolger for helping get this feature ready for production usage.
: