Account registration: Curl error 92 Can not find account id url

Help
1

My domain is: pfsense.home.bartekweb.com

I use the ACME package to attempt register account key and it fails.

It produced this output (slightly redacted):

 readlink exists=0
 dirname exists=0
 Lets find script dir.
 _SCRIPT_='/usr/local/pkg/acme/acme.sh'
 _script='/usr/local/pkg/acme/acme.sh'
 _script_home='/usr/local/pkg/acme'
 Using config home:/tmp/acme/_registerkey/
 ACCOUNT_CONF_PATH='/tmp/acme/_registerkey/accountconf.conf'
 APP
 3:LOG_FILE='/tmp/acme/_registerkey/acme_issuecert.log'
 APP
 4:LOG_LEVEL='3'
 LE_WORKING_DIR='/tmp/acme/_registerkey/'
 Running cmd: registeraccount
 Using config home:/tmp/acme/_registerkey/
 ACCOUNT_CONF_PATH='/tmp/acme/_registerkey/accountconf.conf'
 ACME_DIRECTORY='https://acme-staging-v02.api.letsencrypt.org/directory'
 _ACME_SERVER_HOST='acme-staging-v02.api.letsencrypt.org'
 CA_CONF='/tmp/acme/_registerkey//ca/acme-staging-v02.api.letsencrypt.org/ca.conf'
 Using config home:/tmp/acme/_registerkey/
 ACCOUNT_CONF_PATH='/tmp/acme/_registerkey/accountconf.conf'
 ACME_DIRECTORY='https://acme-staging-v02.api.letsencrypt.org/directory'
 _ACME_SERVER_HOST='acme-staging-v02.api.letsencrypt.org'
 CA_CONF='/tmp/acme/_registerkey//ca/acme-staging-v02.api.letsencrypt.org/ca.conf'
 _regAccount
 _init api for server: https://acme-staging-v02.api.letsencrypt.org/directory
 GET
 url='https://acme-staging-v02.api.letsencrypt.org/directory'
 timeout=
 curl exists=0
 wget exists=127
 _CURL='curl -L --silent --dump-header /tmp/acme/_registerkey//http.header '
 ret='0'
 _json_decode
 _j_str='{
  "K2dMGDeaDB4": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org/docs/staging-environment/"
  },
  "newAccount": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-staging-v02.api.letsencrypt.org/get/draft-aaron-ari/renewalInfo/",
  "revokeCert": "https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
}'
 response='{
  "K2dMGDeaDB4": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org/docs/staging-environment/"
  },
  "newAccount": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-staging-v02.api.letsencrypt.org/get/draft-aaron-ari/renewalInfo/",
  "revokeCert": "https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
}'
 ACME_KEY_CHANGE='https://acme-staging-v02.api.letsencrypt.org/acme/key-change'
 ACME_NEW_AUTHZ
 ACME_NEW_ORDER='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'
 ACME_NEW_ACCOUNT='https://acme-staging-v02.api.letsencrypt.org/acme/new-acct'
 ACME_REVOKE_CERT='https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert'
 ACME_AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf'
 ACME_NEW_NONCE='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'
 ACME_VERSION='2'
 RSA key
 pub_exp='010001'
 base64 single line.
 xxd exists=127
 _URGLY_PRINTF='1'
 e='AQAB'
 modulus='redacted_modulus'
 base64 single line.
 xxd exists=127
 _URGLY_PRINTF='1'
 n='redacted_n'
 jwk='{"e": "AQAB", "kty": "RSA", "n": "redacted_n"}'
 JWK_HEADER='{"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "redacted_n"}}'
 _eab_id='[hidden](please add '--output-insecure' to see this value)'
 _eab_hmac_key='[hidden](please add '--output-insecure' to see this value)'
 OK
 1:CA_EMAIL='myemail@live.com'
 Registering account: https://acme-staging-v02.api.letsencrypt.org/directory
 url='https://acme-staging-v02.api.letsencrypt.org/acme/new-acct'
 payload='{"contact": ["mailto:myemail@live.com"], "termsOfServiceAgreed": true}'
 Use cached jwk for file: /tmp/acme/_registerkey//ca/acme-staging-v02.api.letsencrypt.org/account.key
 base64 single line.
 payload64='redacted_payload64'
 _request_retry_times='1'
 Get nonce with HEAD. ACME_NEW_NONCE='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'
 HEAD
 _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'
 body
 _postContentType='application/jose+json'
 curl exists=0
 wget exists=127
 _CURL='curl -L --silent --dump-header /tmp/acme/_registerkey//http.header  -I  '
 _ret='0'
 _headers='HTTP/2 200 
server: nginx
date: Sat, 29 Jan 2022 17:41:09 GMT
cache-control: public, max-age=0, no-cache
link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: redacted_replay-nonce
x-frame-options: DENY
strict-transport-security: max-age=604800

'
 _CACHED_NONCE='redacted_replay-nonce'
 nonce='redacted_replay-nonce'
 protected='{"nonce": "redacted_replay-nonce", "url": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct", "alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "redacted_n"}}'
 base64 single line.
 protected64='redacted_protected64key'
 base64 single line.
 _sig_t='redacted_sig_t'
 sig='rredacted_sig'
 body='{"protected": "redacted_protected", "signature": "redacted_signature"}'
 POST
 _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/new-acct'
 body='{"protected": "redacted_protected", "payload": "redacted_payload", "signature": "redacted_signature"}'
 _postContentType='application/jose+json'
 Http already initialized.
 _CURL='curl -L --silent --dump-header /tmp/acme/_registerkey//http.header '
 Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 92
 _ret='92'
 responseHeaders
 code
 original
 response
 Registered
 responseHeaders
 _accUri
 Can not find account id url.

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is: HE.net

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using:
pfSense (21.05.02) using ACME.SH ( 2.8.8) and acme package version 0.6.10

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

2

CURLE_HTTP2_STREAM (92)
Stream error in the HTTP/2 framing layer.

Uhm... this should not happen.

Why is there a double slash there?

1 Like
3

Not sure why there is a double slash, a bug with the pfSense package or ACME.sh maybe.

This has worked back in October 2021, but there may have been an update to the package on pfSense side since then.

4

That's just a file name. Double slashes are ignored but even if not would not interfere with curl comms. Something else odd is happening.

Does the problem repeat at the same spot each time? If so, I'd guess pfsense interference first but only because I have no better idea :slight_smile:

Can you just do curl's to that. These will give http 405 but curl itself should not fail:

curl -I https://acme-staging-v02.api.letsencrypt.org/acme/new-acct
2 Likes
5 
/root: curl -I https://acme-staging-v02.api.letsencrypt.org/acme/new-acct
HTTP/2 405
server: nginx
date: Tue, 01 Feb 2022 16:42:52 GMT
content-type: application/problem+json
content-length: 103
allow: POST
cache-control: public, max-age=0, no-cache
link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: 0001mvIRnbcQT5rykUvELDqkpyQU8MtqMwmjNnoBZ22uEJw
6

so a single request is OK . what about retry acme and series of curl's

2 Likes
7

Yes, it repeats at the same spot, as far as I can tell (not an expert), with the same error 92 and message.

I'm not sure what you meant here "what about retry acme and series of curl's"

8

Oh, the acme script is running a series of curl requests to obtain the cert. The first couple curls succeeded but the POST failed. My sample curl was a get for the URL that is failing just to see. It was not a great test as it used a GET where the failing one was a POST with data.

But, I agree with @9peppe the curl 92 failure just should not happen. More likely a network setup issue on your premises. Possibly pfsense. If was fault at Let's Encrypt servers we would be having thousands of complaints this morning

Maybe someone else has better ideas but that's all I can offer.

2 Likes
9

Does this packet capture yield any clues:

11:23:04.479673 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    73.X.X.190.10062 > 172.65.46.172.443: Flags [.], cksum 0xe399 (incorrect -> 0xa7f5), seq 2926, ack 3486, win 515, length 0
11:23:19.840655 IP (tos 0x20, ttl 57, id 18219, offset 0, flags [DF], proto TCP (6), length 52)
    172.65.46.172.443 > 73.X.X.190.10062: Flags [.], cksum 0x71fc (correct), seq 3485, ack 873, win 72, options [nop,nop,sack 1 {2273:2926}], length 0
11:23:19.843104 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    73.X.X.190.10062 > 172.65.46.172.443: Flags [.], cksum 0xe399 (incorrect -> 0xa7f5), seq 2926, ack 3486, win 515, length 0
11:23:34.019257 IP (tos 0x20, ttl 57, id 18220, offset 0, flags [DF], proto TCP (6), length 87)
    172.65.46.172.443 > 73.X.X.190.10062: Flags [P.], cksum 0x7804 (correct), seq 3486:3521, ack 873, win 72, options [nop,nop,sack 1 {2273:2926}], length 35
11:23:34.021719 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    73.X.X.190.10062 > 172.65.46.172.443: Flags [.], cksum 0xe399 (incorrect -> 0xa7d2), seq 2926, ack 3521, win 515, length 0
10

Not to me :slight_smile:

What was your original acme.sh command? You might want to post this problem at the acme.sh github and see if anyone there has ideas.

2 Likes
11

Actually, I solved my own issue. Your responses were helpful in leading me to the solution, which was disabling traffic shaping "limiter" rules on my floating WAN interface.

2 Likes
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.