Perché ACME / Let's Encrypt richiede un record non CNAME?

Question

Perché ACME / Let's Encrypt richiede un record non CNAME?

#1 da (4 voti)
#2 da (1 voti)

6

Sto usando ngrok per dimostrare il protocollo ACME su IIS / Windows. Tuttavia, questo servizio preferisce CNAME su record A.

Nel debugging dell'interazione sembra che ACME ammetta solo i record A. Qual è la logica di sicurezza per questo comportamento? Che alternativa c'è?

Messaggio di errore qui:

    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "DNS problem: SERVFAIL looking up A for dev.server.com",
        "status": 400
      },

dns tls letsencrypt

posta random65537 19.08.2016 - 21:21

fonte

2 risposte

Leggi altre domande sui tag dns tls letsencrypt

Diffie Hellman Group Corrispondenza all'algoritmo di crittografia IPSec più elenchi di dadi per creare passphrase memorabili?

score 4 · Answer 1

La risposta di sebastian nielsen è sbagliata nella misura in cui il buco della sicurezza era in un servizio non correlato chiamato startencrypt. L'implicazione che Letsencrypt non supporti i record CNAME è anch'essa errata come verificato da questo thread e molti altri dove i moderatori di Letsencrypt assicurano che supportano i record CNAME. In effetti, ho appena superato la verifica per un sottodominio che ho indicato su una macchina virtuale di Azure utilizzando un record CNAME.

Il messaggio di errore certbot dà, quando qualcosa è sbagliato è piuttosto fuorviante e non ho trovato nulla nei documenti ufficiali sul supporto CNAME, portando a tutta questa confusione.

score 1 · Answer 2

La ragione di ciò è che è possibile generare certificati per siti che non possiedi se autorizzi CNAME.

C'era un buco di sicurezza, in cui era possibile impostare un proprio CNAME come "yoursite.com CNAME google.com" e quindi è stato in grado di generare un certificato per google.com. Lo stesso problema esisteva con i reindirizzamenti, in cui è possibile impostare un reindirizzamento e causare l'emissione di un certificato non autorizzato.

Tuttavia, invece di correggere il buco effettivo ricontrollando l'indirizzo dopo aver inciampato su un CNAME / reindirizzamento, hanno semplicemente bloccato i reindirizzamenti e i CNAME non sono consentiti.