Required extension OID 1.3.6.1.5.5.7.1.31 is not present - ALPN - mod_md

Domain: Trial-hardware.accessanywhere.net

Completely hand built environment.

Apache 2.4.41
OpenSSL 1.1.1l
mod_md: 2.4.0

httpd.conf

MDCertificateAgreement accepted
WatchdogInterval 1

MDCertificateAuthority https://acme-v02.api.letsencrypt.org/directory

Protocols h2 http/1.1 acme-tls/1
ServerName trial-hardware.accessanywhere.net

This environment sometime the past worked. But it's been a while since I've played with it. I cannot be certain when it last worked but https://crt.sh/?q=trial-hardware.accessanywhere.net implies as recently as Sept 2022.

I've tried clearing out the md directories to force from scratch. But whenever I try to use the tls-alpn method now I always get the following error in my httpd error logs

ACME server authz: challenge 'invalid' for trial-hardware.accessanywhere.net at https://acme-v02.api.letsencrypt.org/acme/authz-v3/164530956286. Exact response was: {"identifier":{"type":"dns","value":"trial-hardware.accessanywhere.net"},"status":"invalid","expires":"2022-10-21T17:03:16Z","challenges":[{"type":"tls-alpn-01","status":"invalid","error":{"type":"urn:ietf:params:acme:error:unauthorized","detail":"Incorrect validation certificate for tls-alpn-01 challenge. Requested trial-hardware.accessanywhere.net from 72.139.112.98:443. Received certificate with unexpected extensions: \\"Required extension OID 1.3.6.1.5.5.7.1.31 is not present\\"","status":403},"url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/164530956286/inkPlg","token":"xxxxxxxx","validationRecord":[{"hostname":"trial-hardware.accessanywhere.net","port":"443","addressesResolved":["72.139.112.98"],"addressUsed":"72.139.112.98"}],"validated":"2022-10-14T17:03:18Z"}]}

The challenge crt.pem has the OID in it.

 X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name: 
                DNS:trial-hardware.accessanywhere.net
            1.3.6.1.5.5.7.1.31: critical
                . p.(......W.xl.57.....&.c..</..07
    Signature Algorithm: sha256WithRSAEncryption
  • Although I'm a little suspicious of the odd characters in the line after the OID
>> Can curl to API fine
/opt/aa/conf# curl -v https://acme-v02.api.letsencrypt.org/directory
* Trying 172.65.32.248:443...
* TCP_NODELAY set
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=acme-v02.api.letsencrypt.org
* start date: Sep 8 19:39:52 2022 GMT
* expire date: Dec 7 19:39:51 2022 GMT
* subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8081770)
> GET /directory HTTP/2
> Host: acme-v02.api.letsencrypt.org
> User-Agent: curl/7.66.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx
< date: Fri, 14 Oct 2022 17:12:26 GMT
< content-type: application/json
< content-length: 659
< cache-control: public, max-age=0, no-cache
< x-frame-options: DENY
< strict-transport-security: max-age=604800
<
{
"E8oLuBbs8IM": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
"keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf",
"website": "https://letsencrypt.org"
},
"newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
"newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
"revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
* Connection #0 to host acme-v02.api.letsencrypt.org left intact

Hi @deepreel, and welcome to the LE community forum :slight_smile:

Please read:
Changes to TLS-ALPN-01 challenge validation - API Announcements - Let's Encrypt Community Support (letsencrypt.org)

2 Likes

Yes I'm aware of that item, but I believe the version of mod_md that I'm using is using the write OID.

In the source code for it in md_crypt.c there is:

#define MD_OID_ACME_VALIDATION_NUM "1.3.6.1.5.5.7.1.31"
#define MD_OID_ACME_VALIDATION_SNAME "pe-acmeIdentifier"
#define MD_OID_ACME_VALIDATION_LNAME "ACME Identifier"

As well in the challenge Certificate (if I'm correct in that this is essentially the request) there is the 1.31 OID. As well those changes were in Jan 2022. If you look at the crt.sh query you see this domain has had a number of certs initialized since then.

I can't move (easily) to a higher version of mod_md that 2.4.0 (I realize this isn't a LE project) since I'd need to bump my apache up as well.

Is there a way to verify the request?

Deep

@rg305 the contents of the certificate currently being presented by trial-hardware.accessanywhere.net are not relevant unfortunately; this is about the contents of the certificate presented by that domain when a client (generally only an ACME server) attempts to connect to it and negotiates the acme-tls/1 protocol for validation of domain control.

@deepreel The "odd characters in the line after the OID" are intended to be there: they're openssl's best-effort attempt to print the binary DER encoding of the Key Authorization for this acme domain control validation challenge: RFC 8737: Automated Certificate Management Environment (ACME) TLS Application‑Layer Protocol Negotiation (ALPN) Challenge Extension

I suspect that what's happening is that the challenge crt.pem is not actually being presented by your webserver when it receives Let's Encrypt's request to connect and negotiate the acme-tls/1 protocol.

6 Likes

Hrmm, interesting..but it writes it out (i.e. i start with a clean md directory)..wonder if it's some odd perms problem.

@aarongable

Is there any way to test that - like by using OpenSSL or cURL ???

2 Likes

This was less than useful:

2 Likes

Ok so I've been experimenting with upgrading environments. I've got this working properly in the "pristine" environment...busted in upgraded environment so something else must be amiss...If I see a solution I'll post.

1 Like

[I don't know how accurate this is... but]
I found this APLN test online:

HTTP/2 Test - Verify HTTP/2 Support | KeyCDN Tools
image

Seems like it works:
HTTP/2 Test - Verify HTTP/2 Support | KeyCDN Tools
image

2 Likes

And from here Toolbox there is a tests for HTTP/2
Check if HTTP/2 is enabled - Geekflare Tools

1 Like

We're looking specifically for a way to test ALPN.

2 Likes

Then there is this one also https://http2.pro/
Online tool to check server HTTP/2, ALPN, and Server-push support.

1 Like

I'm not concerned with ALPN itself..there is something else tricky going on here. See my previous post...pristine environment is fine...upgraded environment causing the issue...overall w.r.t to original topic all likely a red herring...other than potential value of determining a circumstance that can cause this issue. Will advise.

Yet now https://letsdebug.net/ tls-alpn-01 is passing

1 Like

Ok folks, sorry for the distraction.

For the record the issue was a mismatched openssl.cnf file. It was configured for using the Padlock encryption engine, which my openssl didn't have support compiled into it for. Moving to more generic .cnf file fixed things up.

For future noob running LogLevel md:trace3 revealed

Invalid argument: error loading pkey /opt/aa/md/challenges/xxxxxxxx/acme-tls-alpn-01-privkey.pem: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt (pass phrase was not null)

which led me into looking at openssl.

Thanks for everyone's help.

4 Likes

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