Passa al contenuto principale

3. TLS ALPN Challenge (Sfida TLS ALPN)

3. TLS with Application-Layer Protocol Negotiation (TLS ALPN) Challenge (Sfida TLS ALPN)​

Il metodo di convalida TLS con Application-Layer Protocol Negotiation (ALPN) dimostra il controllo su un nome di dominio richiedendo che il client ACME configuri un server TLS per rispondere a tentativi di connessione specifici usando l'estensione ALPN con informazioni identificative. Il server ACME convalida il controllo del nome di dominio connettendosi a un server TLS a uno degli indirizzi risolti per il nome di dominio e verificando che venga presentato un certificato con contenuto specifico.

L'oggetto challenge ACME tls-alpn-01 ha il formato seguente:

type (obbligatorio, stringa): la stringa tls-alpn-01

token (obbligatorio, stringa): un valore casuale che identifica in modo univoco la challenge. Questo valore DEVE avere almeno 128 bit di entropia. NON DEVE contenere caratteri al di fuori dell'alfabeto base64url descritto nella sezione 5 di [RFC4648]. I caratteri di padding = finali DEVONO essere rimossi. Vedere [RFC4086] per ulteriori informazioni sui requisiti di casualità.

Il client si prepara alla convalida costruendo un certificato autofirmato che DEVE contenere un'estensione acmeIdentifier e un'estensione subjectAlternativeName [RFC5280]. L'estensione subjectAlternativeName DEVE contenere una singola voce dNSName il cui valore è il nome di dominio in convalida. L'estensione acmeIdentifier DEVE contenere il digest SHA-256 [FIPS180-4] della key authorization (autorizzazione della chiave) [RFC8555] per la challenge. L'estensione acmeIdentifier DEVE essere critica affinché il certificato non venga usato inavvertitamente da software non ACME.

L'estensione acmeIdentifier è identificata dall'object identifier (OID) id-pe-acmeIdentifier nell'arco id-pe [RFC5280]:

id-pe-acmeIdentifier OBJECT IDENTIFIER ::=  { id-pe 31 }

L'estensione ha il formato ASN.1 [X.680] seguente:

Authorization ::= OCTET STRING (SIZE (32))

L'extnValue dell'estensione id-pe-acmeIdentifier è la codifica ASN.1 DER [X.690] della struttura Authorization, che contiene il digest SHA-256 della key authorization per la challenge.

Una volta creato questo certificato, DEVE essere predisposto in modo che venga restituito durante un handshake TLS in cui è stato negoziato il protocollo di strato applicativo acme-tls/1 e è stata fornita un'estensione Server Name Indication (SNI) [RFC6066] contenente il nome di dominio in convalida.

Un client risponde inviando tramite POST un oggetto JSON vuoto ({}) all'URL della challenge per confermare che la challenge è pronta per essere convalidata dal server. La codifica base64url delle intestazioni protette e del payload è descritta nella sezione 6.1 di [RFC8555].

POST /acme/authz/1234/1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/1",
    "nonce": "JHb54aT_KTXBWQOzGYkt9A",
    "url": "https://example.com/acme/authz/1234/1"
  }),
  "payload": base64url({}),
  "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}

Alla ricezione di questa richiesta da un client, il server costruisce e memorizza la key authorization dal valore token della challenge e dalla chiave dell'account client attuale.

Il server verifica quindi il controllo del dominio da parte del client verificando che il server TLS sia stato configurato come previsto con i passaggi seguenti:

  1. Il server ACME calcola il digest SHA-256 atteso della key authorization.

  2. Il server ACME risolve il nome di dominio in convalida e sceglie uno degli indirizzi IP restituiti per la convalida (il server PUÒ convalidare rispetto a più indirizzi se ne viene restituito più di uno).

  3. Il server ACME avvia una connessione TLS all'indirizzo IP scelto. Questa connessione DEVE usare la porta TCP 443. Il server ACME DEVE fornire un'estensione ALPN con il solo nome di protocollo acme-tls/1 e un'estensione SNI contenente solo il nome di dominio in convalida durante l'handshake TLS.

  4. Il server ACME verifica che durante l'handshake TLS il protocollo di strato applicativo acme-tls/1 sia stato negoziato con successo (e che l'estensione ALPN contenesse solo il valore acme-tls/1) e che il certificato restituito contenga:

    • un'estensione subjectAltName contenente il dNSName in convalida e nessun'altra voce

    • un'estensione acmeIdentifier critica contenente il digest SHA-256 atteso calcolato al passo 1

Il confronto dei dNSName DEVE essere case insensitive [RFC4343]. Si noti che poiché ACME non supporta identificatori Unicode, tutti i dNSName DEVONO essere codificati secondo le regole di [RFC3492].

Se tutti i passaggi precedenti hanno esito positivo, la convalida ha successo. Altrimenti fallisce.

Ultimo aggiornamento il