Originally created by @colin-stubbs on GitHub (May 28, 2020).
The current code within sign_csr() that tries to determine the token to use with the selected challenge type seems to fail to pick the correct token.
If dehydrated is configured to perform dns-01 validation, but the ACME API returns all three challenge types (dns-01, tls-alpn-01, http-01) BUT with different token values for each, the token value from the last entry in the list is used.
e.g. the token value specific to the http-01 challenge is used by dehydrated as part of dns-01 (hook deploys DNS record), and the DigiCert ACMEv2 API when asked to verify that token (it's the http-01 NOT the dns-01 value) it goes ahead and correctly performs a check for http-01 token via HTTP instead of dns-01 via DNS.
The issue is in sign_csr() when it iterates over the list of challenges return in the JSON payload from this response,
Originally created by @colin-stubbs on GitHub (May 28, 2020).
The current code within sign_csr() that tries to determine the token to use with the selected challenge type seems to fail to pick the correct token.
If dehydrated is configured to perform dns-01 validation, but the ACME API returns all three challenge types (dns-01, tls-alpn-01, http-01) BUT with different token values for each, the token value from the last entry in the list is used.
e.g. the token value specific to the http-01 challenge is used by dehydrated as part of dns-01 (hook deploys DNS record), and the DigiCert ACMEv2 API when asked to verify that token (it's the http-01 NOT the dns-01 value) it goes ahead and correctly performs a check for http-01 token via HTTP instead of dns-01 via DNS.
The issue is in sign_csr() when it iterates over the list of challenges return in the JSON payload from this response,
```
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 27 May 2020 23:07:02 GMT
Content-Type: application/json
Content-Length: 892
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Cache-Control: public, max-age=0, no-cache
Link: <https://acme.digicert.com/v2/acme/account/SECRET_UNIQUE_ACCOUNT_VALUE>;rel="up"
Location: https://acme.digicert.com/v2/acme/authz/SECRET_UNIQUE_ACCOUNT_VALUE/UNIQUE_REQUEST_VALUE
Replay-Nonce: NONCE_VALUE
X-Correlation-Id: F19D8DE2-CC90-52BC-0422-3BD27D01069F
X-Hostname: enrollme05.slc.digicert.com
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
{
"challenges": [
{
"status": "pending",
"token": "kea-gtCl0nnJqDHu05N3JD3s-zwQNiXU",
"type": "dns-01",
"url": "https://acme.digicert.com/v2/acme/challenge/SECRET_UNIQUE_ACCOUNT_VALUE/UNIQUE_REQUEST_VALUE/q2quuRXWzp8LhnLj"
},
{
"status": "pending",
"token": "4tUeO_9MxeWFl8pGflNQMxnBQV1xpT-2",
"type": "tls-alpn-01",
"url": "https://acme.digicert.com/v2/acme/challenge/SECRET_UNIQUE_ACCOUNT_VALUE/UNIQUE_REQUEST_VALUE/DilxB7yuGKKjXii4"
},
{
"status": "pending",
"token": "4ZDSajMX7nzWR2diVSs6alSCHQVlxuKJ",
"type": "http-01",
"url": "https://acme.digicert.com/v2/acme/challenge/SECRET_UNIQUE_ACCOUNT_VALUE/UNIQUE_REQUEST_VALUE/iH1RuwXGm4tHWU62"
}
],
"expires": "2020-05-29T17:07:00-06:00",
"identifier": {
"type": "dns",
"value": "sub.domain.tld"
},
"status": "pending",
"wildcard": false
}
```
Summary of issues found in DigiCert ACME API endpoint:
TAB characters included with spaces in body of response, e.g. inside JSON formatted content, have to update clean_json() function to replaces any instance of space and/or tab with single space
challenges was being extracted from JSON response using weird sed regex match when it should be using the standard get_json_array_value function
Even though challenge has been completed successfully, DigiCert ACMEv2 API may respond with "processing" instead of "pending", where Let's Encrypt will always respond with "pending"... "processing" is a valid status according to RFC8555 and seems to indicate the same thing... that the ACME client should back off and try again shortly.
@colin-stubbs commented on GitHub (May 28, 2020):
Summary of issues found in DigiCert ACME API endpoint:
1. TAB characters included with spaces in body of response, e.g. inside JSON formatted content, have to update clean_json() function to replaces any instance of space and/or tab with single space
2. challenges was being extracted from JSON response using weird sed regex match when it should be using the standard get_json_array_value function
2. Even though challenge has been completed successfully, DigiCert ACMEv2 API may respond with "processing" instead of "pending", where Let's Encrypt will always respond with "pending"... "processing" is a valid status according to RFC8555 and seems to indicate the same thing... that the ACME client should back off and try again shortly.
@colin-stubbs Can you check my pull request? It's essentially a rebase of your patch to master (which uses json.sh).
@danimo commented on GitHub (Sep 2, 2020):
@colin-stubbs Can you check my pull request? It's essentially a rebase of your patch to master (which uses json.sh).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @colin-stubbs on GitHub (May 28, 2020).
The current code within sign_csr() that tries to determine the token to use with the selected challenge type seems to fail to pick the correct token.
If dehydrated is configured to perform dns-01 validation, but the ACME API returns all three challenge types (dns-01, tls-alpn-01, http-01) BUT with different token values for each, the token value from the last entry in the list is used.
e.g. the token value specific to the http-01 challenge is used by dehydrated as part of dns-01 (hook deploys DNS record), and the DigiCert ACMEv2 API when asked to verify that token (it's the http-01 NOT the dns-01 value) it goes ahead and correctly performs a check for http-01 token via HTTP instead of dns-01 via DNS.
The issue is in sign_csr() when it iterates over the list of challenges return in the JSON payload from this response,
@colin-stubbs commented on GitHub (May 28, 2020):
Example from Let's Encrypt, where token values are all the same... so the assumption that the last token value can be used still works.
@colin-stubbs commented on GitHub (May 28, 2020):
Summary of issues found in DigiCert ACME API endpoint:
@colin-stubbs commented on GitHub (May 28, 2020):
Tested against both Let's Encrypt and DigiCert... DigiCert failing for somewhat expected reason now, e.g. no funds to use for cert.
@danimo commented on GitHub (Sep 2, 2020):
@colin-stubbs Can you check my pull request? It's essentially a rebase of your patch to master (which uses json.sh).
@lukas2511 commented on GitHub (Dec 10, 2020):
I think this should be fixed by now, otherwise please comment or feel free to open a new issue.