Não é possível passar o desafio TLS-SNI-01 com Let's Encrypt / Certbot - como consertar?

1

Estou executando o Ubuntu 14.04LTS. Eu peguei certbot-auto do site da EFF já que o certbot não está em 14.04.

Eu tentei executá-lo como

certbot-auto --apache -d my.domain

e sempre expira durante o desafio TLS-SNI-01 com a seguinte mensagem:

Failed authorization procedure. my.domain (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to ww.xx.yy.zz:443 for TLS-SNI-01 challenge

Verifiquei que o TLS de entrada não está sendo bloqueado executando o comando s_server do openssl e conectando-se com êxito ao s_server "servidor" de locais externos.

Olhando para /var/log/apache2/error.log , vejo um aviso suspeito sobre (suponho) que o docroot que certbot-auto está tentando configurar temporariamente não foi encontrado:

[Tue Dec 06 00:34:02.306032 2016] [mpm_prefork:notice] [pid 19521] AH00171: Graceful restart requested, doing restart
[Tue Dec 06 00:34:03.001014 2016] [mpm_prefork:notice] [pid 19521] AH00163: Apache/2.4.7 (Ubuntu) configured -- resuming normal operations
[Tue Dec 06 00:34:03.001094 2016] [core:notice] [pid 19521] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 06 00:34:14.596461 2016] [mpm_prefork:notice] [pid 19521] AH00171: Graceful restart requested, doing restart
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
[Tue Dec 06 00:34:14.661372 2016] [ssl:warn] [pid 19521] AH01906: RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Tue Dec 06 00:34:15.000674 2016] [mpm_prefork:notice] [pid 19521] AH00163: Apache/2.4.7 (Ubuntu) OpenSSL/1.0.1f configured -- resuming normal operations
[Tue Dec 06 00:34:15.001293 2016] [core:notice] [pid 19521] AH00094: Command line: '/usr/sbin/apache2'

Em /var/log/letsencrypt/letsencrypt.log , vejo o seguinte, que parece totalmente razoável:

2016-12-06 05:34:13,247:INFO:certbot.auth_handler:Performing the following challenges:
2016-12-06 05:34:13,268:INFO:certbot.auth_handler:tls-sni-01 challenge for mydomain.com
2016-12-06 05:34:13,359:INFO:certbot_apache.configurator:Enabled Apache socache_shmcb module
2016-12-06 05:34:13,520:INFO:certbot_apache.configurator:Enabled Apache ssl module
2016-12-06 05:34:14,345:DEBUG:certbot_apache.tls_sni_01:Adding Include /etc/apache2/le_tls_sni_01_cert_challenge.conf to /files/etc/apache2/apache2.conf
2016-12-06 05:34:14,351:DEBUG:certbot_apache.tls_sni_01:writing a config file with text:
 <IfModule mod_ssl.c>
<VirtualHost *>
    ServerName b103a17811594b35d3ade8eb763c8c42.74b423d383109b22eaecca3ea14cd1f7.acme.invalid
    UseCanonicalName on
    SSLStrictSNIVHostCheck on

    LimitRequestBody 1048576

    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /var/lib/letsencrypt/mRH5i2aIrWMqjsZn3jMXvdNnYV5Ejd0GBtcDoIJqQ4U.crt
    SSLCertificateKeyFile /var/lib/letsencrypt/mRH5i2aIrWMqjsZn3jMXvdNnYV5Ejd0GBtcDoIJqQ4U.pem

    DocumentRoot /var/lib/letsencrypt/tls_sni_01_page/
</VirtualHost>

</IfModule>

Se eu assistir /var/lib/letsencrypt enquanto certbot-auto for executado, eu nunca verei um tls_sni_01_page sendo criado. Aqui está a sequência que vejo - um diretório temporário e alguns certificados temporários sendo feitos e, em seguida, excluídos quando o desafio falha, mas nunca tls_sni_01_page

/var/lib/letsencrypt$ ls
backups
/var/lib/letsencrypt$ ls
backups
/var/lib/letsencrypt$ ls
backups
/var/lib/letsencrypt$ ls
backups  temp_checkpoint
/var/lib/letsencrypt$ ls
backups  temp_checkpoint
/var/lib/letsencrypt$ ls
backups  e1pvy9TgUvOmBxC4dlkwG5Ly2mTY0DU63qhUFpBik2Y.crt  e1pvy9TgUvOmBxC4dlkwG5Ly2mTY0DU63qhUFpBik2Y.pem  temp_checkpoint

Eu também alterei /etc/letsencrypt/options-ssl-apache.conf para definir o nível de log como DEBUG e para que o log de host virtual temporário tenha seu próprio erro e acesse os logs. Eu vejo a saída, mas não há problemas no log de erros, mas não vejo nada no log de acesso.

Eu tentei executar tcpdump -n port 443 e faço ver algum tipo de tentativa de conexão da máquina remota:

09:14:44.388328 IP 66.133.109.36.48890 > w.x.y.z.443: Flags [S], seq 1627589669, win 29200, options [mss 1460,sackOK,TS val 2834688174 ecr 0,nop,wscale 7], length 0
09:14:44.388435 IP w.x.y.z.443 > 66.133.109.36.48890: Flags [S.], seq 773250860, ack 1627589670, win 28960, options [mss 1460,sackOK,TS val 424229197 ecr 2834688174,nop,wscale 7], length 0
09:14:44.451190 IP 66.133.109.36.48890 > w.x.y.z.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 2834688237 ecr 424229197], length 0
09:14:44.451546 IP 66.133.109.36.48890 > w.x.y.z.443: Flags [P.], seq 1:220, ack 1, win 229, options [nop,nop,TS val 2834688237 ecr 424229197], length 219
09:14:44.451619 IP w.x.y.z.443 > 66.133.109.36.48890: Flags [.], ack 220, win 235, options [nop,nop,TS val 424229216 ecr 2834688237], length 0
09:14:44.454461 IP w.x.y.z.443 > 66.133.109.36.48890: Flags [P.], seq 1:393, ack 220, win 235, options [nop,nop,TS val 424229217 ecr 2834688237], length 392
09:14:44.454626 IP w.x.y.z.443 > 66.133.109.36.48890: Flags [F.], seq 393, ack 220, win 235, options [nop,nop,TS val 424229217 ecr 2834688237], length 0
09:14:44.517433 IP 66.133.109.36.48890 > w.x.y.z.443: Flags [.], ack 393, win 237, options [nop,nop,TS val 2834688303 ecr 424229217], length 0
09:14:44.517481 IP 66.133.109.36.48890 > w.x.y.z.443: Flags [P.], seq 220:227, ack 394, win 237, options [nop,nop,TS val 2834688303 ecr 424229217], length 7
09:14:44.517514 IP 66.133.109.36.48890 > w.x.y.z.443: Flags [F.], seq 227, ack 394, win 237, options [nop,nop,TS val 2834688303 ecr 424229217], length 0
09:14:44.517544 IP w.x.y.z.443 > 66.133.109.36.48890: Flags [.], ack 228, win 235, options [nop,nop,TS val 424229235 ecr 2834688303], length 0

Alguma ideia do que diabos está acontecendo? Alguém já conseguiu isso trabalhando com o Ubuntu 14.04LTS e apache?

    
por QuantumMechanic 06.12.2016 / 06:47

2 respostas

2

Eu lutei com isso por várias horas, completa com a mesma saída em meus logs. Eu só tropecei na minha resposta. Eu tinha colado algum código de outro webconfig e ele já tinha uma seção <virtual host _._._._:443> nele. Eu alterei, mas deixei. Depois de excluir essa seção 443, o sudo certbot-auto --apache -d example.com correu sem erro e eu tinha um site de trabalho.

Estou tirando conclusões apenas da minha experiência: verifique se você tem apenas hosts virtuais para a porta 80. Em nenhum lugar da documentação que li mencionou esse problema, mas parece que o certbot não pode alterar uma seção de host virtual 443, só pode Adicione um.

EDIT - Dez / 2017 Agora posso executar o certbot no site-available.conf com <virtual host *:443> neles. Todas as minhas modificações personalizadas foram mantidas intactas, minha única queixa é que as linhas do caminho do certificado não foram recuadas. < suspiro < Oh, bem! < / suspiro >

    
por 05.01.2017 / 20:21
1

Você pode tentar a validação de desafio independente. Isso ignora o apache e deve resolver o seu problema com certbot , não criando os arquivos corretos na raiz da WWW.

  1. pare o apache
  2. executar certbot-auto --standalone-supported-challenges tls-sni-01 -d my.domain
  3. instale o certificado que você recebeu no lugar certo (provavelmente /etc/apache2/ssl )
  4. inicie o apache e teste
por 09.12.2016 / 11:52