Add support for ACME challengeless support using only EAB

[azaleski-sd]

Proposed changes

Challengeless ACME: support ACME servers that pre-authorize identifiers (e.g. via EAB) and don't require http-01 / tls-alpn-01. Support additional CSR subject fields - new csr_additional_fields directive to set O, OU, C, L, ST in the certificate signing request. Useful to support internal PKI providers like Venafi which issue certificates to services hosted in corporate networks to which issuer doesn't have access.

We're running nginx with this change in our corporate network and didn't notice any issues so far.

Detailed description:

1. challenge none (alias off): skips the challenge flow; no solver registered.
2. get_nonce: uses HEAD on new_nonce per RFC 8555 §7.2.
3. Order:authorizations is now optional during deserialization. Some providers like Venafi require it if ACME is done only using EAB.
4. csr_additional_fields key=value ... (new acme_issuer directive): sets organization, organizational_unit, country, locality, state on the CSR. Rejects unknown keys, missing =, empty values, and duplicates.
5. README updated
6. Added tests

Checklist

Before creating a PR, run through this checklist and mark each as complete:

• I have read the contributing guidelines.
• I have signed the F5 Contributor License Agreement (CLA).
• If applicable, I have added tests that prove my fix is effective or that my feature works.
• If applicable, I have checked that any relevant tests pass after adding my changes.
• I have updated any relevant documentation (README.md and/or CHANGELOG.md).

[github-actions]

✅ All required contributors have signed the F5 CLA for this PR. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[azaleski-sd]

I have hereby read the F5 CLA and agree to its terms

[azaleski-sd]

recheck

[bavshin-f5]

• challenge none (alias off): skips the challenge flow; no solver registered.

This should not be necessary; challenge configured supported challenges as opposed to required. If the ACME server does not request any authorizations, no challenges would be performed.

• get_nonce: uses HEAD on new_nonce per RFC 8555 §7.2.

Any compliant ACMEv2 (RFC 8555) implementation MUST allow GET requests for the newNonce resource (RFC8555 § 7.2, RFC8555 § 6.3).

The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

An error response for GET may contain additional error details, so I'd prefer to keep the current method.

• Order:authorizations is now optional during deserialization. Some providers like Venafi require it if ACME is done only using EAB.

Hm...

   authorizations (required, array of string):  For pending orders, the
      authorizations that the client needs to complete before the
      requested certificate can be issued

I'm starting to suspect that Venafi does not implement all the required parts of RFC 8555, despite their claims. At least this one does not have a noticeable maintenance cost.

Do you mind moving the change to a separate commit?

• csr_additional_fields key=value ... (new acme_issuer directive): sets organization, organizational_unit, country, locality, state on the CSR. Rejects unknown keys, missing =, empty values, and duplicates.

This one is a bit dangerous.

Baseline Requirements for TLS Server Certificates 7.1.2.7.2 states that the only allowed Subject attributes for a Domain Validated certificate are countryName and commonName. Neither are recommended.
Other types of Subscriber Certificates may contain additional attributes that must be verified by the CA by means not specified in the ACME protocol.

Most of the public services will either ignore or reject CSRs with additional Subject attributes. Therefore, csr_additional_fields can be easily misused, resulting in an obscure urn:ietf:params:acme:error:badCsr error.

I'm really hesitant about allowing this, especially when there's no similar functionality in other popular clients.

[azaleski-sd]

@bavshin-f5 Just to be clear. We don't have problem with other acme clients. These changes are just to make nginx compatible with other ACME vendors just like rest of the clients like win-acme.

This should not be necessary; challenge configured supported challenges as opposed to required. If the ACME server does not request any authorizations, no challenges would be performed.

The default value of this field is http-01. So first, for consistency there should be explicit option to tell that we don't want any challenges to be performed. And my tests shown that leaving this value set to default won't make it compatible with challengeless endpoints as nginx will throw error when it can't find supported chellange.

Any compliant ACMEv2 (RFC 8555) implementation MUST allow GET requests for the newNonce resource (RFC8555 § 7.2, RFC8555 § 6.3).

True, but other clients like certbot use primarily HEAD, not even considering GET. e.g. https://github.com/certbot/certbot/blob/750b9997defdf3be12f826d7e2ea98e7c7572076/acme/src/acme/client.py#L793

Can't we also support HEAD as it is primary method for this type of requests?

Unfortunately world is like this so not everyone implement spec fully, but they just want to make this compatible with the most popular tools.

Do you mind moving the change to a separate commit?

Done: https://github.com/nginx/nginx-acme/pull/178/changes . As mentioned before, that's true that they don't fully implement spec. However other acme clients tolerate these behaviours.

I'm really hesitant about allowing this, especially when there's no similar functionality in other popular clients.

There is. Cert-manager has literalSubject field: https://cert-manager.io/docs/usage/certificate/. Tools like certbot or win-acme have ability to use own CSR file.