Certbot: Nenhum vhost foi selecionado

@joohoi quer levar isso?

@hugo-connery o fato de você ter uma diretiva ServerName deve ser suficiente para essa configuração funcionar, então acho que isso é definitivamente um bug ...

Sim, eu vou levar isso.

@hugo-connery obrigado pelas extensas informações sobre o meio ambiente! No entanto, se você puder nos enviar a saída de:

python -c 'importar plataforma;print([platform.system(),platform.linux_distribution()[0]])'

para garantir que acabamos usando o layout e os padrões corretos do sistema para sua distribuição (quer verificar se estamos realmente procurando os caminhos corretos para os vhosts)

Oi,

Sem problemas. Vai fazer. Agradeço a resposta rápida.

Viva LE.

Hugo Connery

Chefe de TI, DTU Environment, http://www.env.dtu.dk
Reduza o risco de usar a TI entendendo-a.

De: Joona Hoikkala [[email protected]]
Enviado: quarta-feira, 6 de abril de 2016 19:46
Para: letsencrypt/letsencrypt
CC: Hugo Maxwell Connery
Assunto: Re: [letsencrypt/letsencrypt] Nenhum vhost foi selecionado (#2776)

Sim, eu vou levar isso. @hugo-con neryhttps://github.com/hugo-connery obrigado pelas extensas informações sobre o meio ambiente! No entanto, se você puder nos enviar a saída de:

python -c 'importar plataforma;print([platform.system(),platform.linux_distribution()[0]])'

para garantir que acabamos usando o layout e os padrões corretos do sistema para sua distribuição (quer verificar se estamos realmente procurando os caminhos corretos para os vhosts)

Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no Gi tHubhttps://github.com/letsencrypt/letsencrypt/issues/2776#issuecomment -206484850

Oi,

Não tenho certeza se isso vai te ajudar muito, mas

['Linux', 'CentOS Linux']

é a saída do comando que você deseja que eu execute.

Eu acho que este é um subconjunto das informações
Eu já forneci.

Qualquer que seja.

Hugo Connery

Chefe de TI, DTU Environment, http://www.env.dtu.dk
Reduza o risco de usar a TI entendendo-a.

De: Joona Hoikkala [[email protected]]
Enviado: quarta-feira, 6 de abril de 2016 19:46
Para: letsencrypt/letsencrypt
CC: Hugo Maxwell Connery
Assunto: Re: [letsencrypt/letsencrypt] Nenhum vhost foi selecionado (#2776)

Sim, eu vou levar isso. @hugo-con neryhttps://github.com/hugo-connery obrigado pelas extensas informações sobre o meio ambiente! No entanto, se você puder nos enviar a saída de:

python -c 'importar plataforma;print([platform.system(),platform.linux_distribution()[0]])'

para garantir que acabamos usando o layout e os padrões corretos do sistema para sua distribuição (quer verificar se estamos realmente procurando os caminhos corretos para os vhosts)

Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no Gi tHubhttps://github.com/letsencrypt/letsencrypt/issues/2776#issuecomment -206484850

Sim, são apenas as chamadas reais que estamos usando para obter a string de distribuição / os, então queremos ter certeza de que ela foi detectada corretamente - exatamente como parece ser.

Confirmei que sua configuração do VirtualHost analisa bem, então deve ser algo relacionado ao layout de configuração / padrões de distribuição.

Seu arquivo de configuração do virtualhost reside em /etc/httpd/conf.d e o arquivo de configuração que contém o vhost tem outros vhosts nele?

Talvez outro exemplo disso?

Caso seja, aqui vão algumas informações:
Letsencrypt disse:

We were unable to find a vhost with a ServerName or Address of www.cbmission.org.
Which virtual host would you like to choose?

/etc/apache2/sites-available/cbmission.org.conf diz no topo:

<VirtualHost *:80>
        ServerName cbmission.org
        ServerAlias www.cbmission.org

e depois:

</VirtualHost>
<VirtualHost *:443>
        ServerName cbmission.org
        ServerAlias www.cbmission.org

python -c 'import platform;print([platform.system(),platform.linux_distribution()[0]])' diz:
['Linux', 'Ubuntu']
Observe que essa configuração estava funcionando perfeitamente até eu atualizar para a versão 0.5.0 do cliente hoje. Agora eu tenho que editar manualmente os arquivos de configuração do apache depois que o letsencrypt emite o certificado.

Deixe-me saber se há outras informações que seriam úteis.

Tive o mesmo problema com dois vhosts que estavam perfeitamente configurados antes - e destruídos após o processo de renovação.

Am 07.04.2016 às 21:45 schrieb Bret Miller [email protected] :

Caso seja, aqui vão algumas informações:
Letsencrypt disse:
Não foi possível encontrar um vhost com um nome de servidor ou endereço de
Qual host virtual você gostaria de escolher?

/etc/apache2/sites-available/cbmission.org.conf diz no topo:

ServerName cbmission.org
ServerAlias www.cbmission.org

e depois:

ServerName cbmission.org
ServerAlias www.cbmission.org

python -c 'import platform;print([platform.system(),platform.linux_distribution()[0]])' diz:
['Linux', 'Ubuntu']

Observe que essa configuração estava funcionando perfeitamente até eu atualizar para a versão 0.5.0 do cliente hoje. Agora eu tenho que editar manualmente os arquivos de configuração do apache depois que o letsencrypt emite o certificado.

Deixe-me saber se há outras informações que seriam úteis.

—
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub

@bret-miller & @thorstensiefert & @hugo-connery : você poderia postar o conteúdo do arquivo de log LE em um pastebin caso tenha mais informações sobre isso. O arquivo em questão é /var/log/letsencrypt/letsencrypt.log

Eu fiz vários domínios na sexta-feira. Aqui está o log de então:
http://pastebin.com/tZtV9eks

@bret-miller O arquivo de log não parece ter uma referência à execução com falha que você relatou anteriormente, ou as execuções no log também resultaram em arquivos de configuração igualmente quebrados? Se não, você poderia verificar /var/log/letsencrypt/letsencrypt.log.1 letsencrypt.log.2 e assim por diante, para aquele que tem as informações em execução com o domínio www.cbmission.org

@joohoi Cada execução nesse servidor desde então teve o mesmo problema. Infelizmente, estou no meio da mudança de vários sites do DreamHost para o Google Cloud, onde ocorreu o problema. O arquivo .10 é o mais antigo e é de 08/04/2016. Ele tinha o mesmo problema - apenas um domínio diferente. Um pensamento me ocorreu esta manhã que eu tenho alguns arquivos de configuração padrão do Apache em sites disponíveis que não estão vinculados a sites habilitados. Talvez o fato de não conterem uma diretiva ServerName ou ServerAlias ​​esteja confundindo o cliente LE. Ia tentar excluí-los hoje e tentar outro domínio para ver se isso resolvia o problema ... só não tive a chance ainda.

OK. Isso foi pior. Com o 000-default.conf e o ssl-default.conf no lugar, o cliente LE ainda adquire o certificado para o domínio solicitado e, em seguida, solicita qual .conf atualizar. Então eu 'c' para cancelar e atualizar manualmente o $domain.conf manualmente. Pelo menos isso funciona em torno dele. Quando removo os arquivos .conf padrão, o cliente LE nem tenta obter o certificado. Simplesmente falha.

@bret-miller Ainda não consigo reproduzir o problema, alguma chance de você me fornecer um tarball do seu
/etc/apache2 junto com um arquivo .ini que você está usando?

Conforme solicitado por Joona Hoikkala, aqui estão mais alguns detalhes.

Executei novamente letsencrypt-auto --apache -d sec.it.env.dtu.dk e selecionei 'atualizar' o certificado existente (que eu obtive usando --certonly).

Erro:

Não existe vhost com nome de servidor ou alias de: sec.it.env.dtu.dk. Nenhum vhost foi selecionado. Por favor, especifique os nomes dos servidores na configuração do Apache

A configuração é inalterada de cima (e como você pode ver, declara o vhost).

letsencrypt.log

2016-04-12 07:10:02,451:DEBUG:letsencrypt.main:Nível de registro de raiz definido em 30
2016-04-12 07:10:02,451:INFO:letsencrypt.main:Salvando o log de depuração em /var/log/letsencrypt/letsencrypt.log
2016-04-12 07:10:02,451:DEBUG:letsencrypt.main:letsencrypt versão: 0.5.0
2016-04-12 07:10:02,451:DEBUG:letsencrypt.main:Argumentos: ['--apache', '-d', 'sec.it.env.dtu.dk']
2016-04-12 07:10:02,451:DEBUG:letsencrypt.main:Plugins descobertos: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-04-12 07:10:02,453:DEBUG:letsencrypt.plugins.selection:Apache de autenticador solicitado e apache de instalador
2016-04-12 07:10:03,575:DEBUG:letsencrypt.plugins.selection:Plugin de candidato único: * apache
Descrição: Apache Web Server - Alpha
Interfaces: IAuthenticator, IInstaller, IPlugin
Ponto de entrada: apache = letsencrypt_apache.configurator:ApacheConfigurator
Inicializado:
Preparação: Verdade
2016-04-12 07:10:03,575:DEBUG:letsencrypt.plugins.selection:Autenticador selecionadoe instalador
2016-04-12 07:10:04,183:DEBUG:letsencrypt.main:Conta escolhida: 2016-04-12 07:10:04,184:DEBUG:root:Enviando solicitação GET para https://acme-v01.api.letsencrypt.org/directory. argumentos: (), kwargs: {}
2016-04-12 07:10:04,248:INFO:requests.packages.urllib3.connectionpool:Iniciando nova conexão HTTPS (1): acme-v01.api.letsencrypt.org
2016-04-12 07:10:04,645:DEBUG:requests.packages.urllib3.connectionpool:"GET /directory HTTP/1.1" 200 263
2016-04-12 07:10:04,649:DEBUG:root:Recebido 2016-04-12 07:10:04,650:DEBUG:acme.client:Resposta recebida 2016-04-12 07:10:04,682:INFO:letsencrypt.renewal:Cert ainda não deve ser renovado
2016-04-12 07:10:10,036:DEBUG:root:Solicitando um novo nonce
2016-04-12 07:10:10,037:DEBUG:root:Enviando solicitação HEAD para https://acme-v01.api.letsencrypt.org/acme/new-authz. argumentos: (), kwargs: {}
2016-04-12 07:10:10,040:INFO:requests.packages.urllib3.connectionpool:Iniciando nova conexão HTTPS (1): acme-v01.api.letsencrypt.org
12-04-2016 07:10:10,280:DEBUG:requests.packages.urllib3.connectionpool:"HEAD /acme/new-authz HTTP/1.1" 405 0
2016-04-12 07:10:10,283:DEBUG:root:Received 2016-04-12 07:10:10,285:DEBUG:acme.client:Storing nonce: '\xc2"\xca\n\t\xc41/Up]\xb1\xcd\x02K\xf3\xb3\xf9vC~\xb2wu \x17\xd4G<^\xe8#\x13'
2016-04-12 07:10:10,285:DEBUG:acme.jose.json_util:Campos vazios omitidos: expires=Nenhum, desafios=Nenhum, combinações=Nenhum, status=Nenhum
2016-04-12 07:10:10,286:DEBUG:acme.client:Serialized JSON: {"identifier": {"type": "dns", "value": "sec.it.env.dtu.dk"} , "recurso": "novo-authz"}
2016-04-12 07:10:10,288:DEBUG:acme.jose.json_util:Campos vazios omitidos: x5c=(), crit=(), typ=Nenhum, jwk=Nenhum, x5u=Nenhum, kid=Nenhum, alg =Nenhum, cty=Nenhum, x5tS256=Nenhum, jku=Nenhum, x5t=Nenhum
2016-04-12 07:10:10,293:DEBUG:acme.jose.json_util:Campos vazios omitidos: x5c=(), crit=(), nonce=Nenhum, x5u=Nenhum, typ=Nenhum, kid=Nenhum, cty =Nenhum, x5tS256=Nenhum, jku=Nenhum, x5t=Nenhum
2016-04-12 07:10:10,294:DEBUG:root:Enviando solicitação POST para https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: {'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n ": "sS5EWUuYMMINfHPACFSu6N5aJpOngpp0wiCQkOgTa5Hf3bEslF6H0kAiBFhGYFqOC7vYW9ONYIjmZNRcBSPy4gY2cF5XH5Hzy7iFd5Tyiitl1qe-11VKs-haizb_vA_jDWaUy4n60QyO2RWnxxkUuwZRyWDPX9Et7c5PlEaPKqJPLqZgExRonT6JLudyVpNGVFSxnCNzCBkdBm5KxvhHYzXPijmI4QIjW8e-DHwjKPVXMd6fqe_JtIspaf5R4UJ9DFTVeVxW0n2_m7uP1RbzDPP3tnkGUDk5buIu6fTrmkKH-gvdnVTGJ7vbwPAfdwfl9nA5wOdKGGHl4IJqsk1qoQ"}}, "protegido": "eyJub25jZSI6ICJ3aUxLQ2duRU1TOVZjRjJ4elFKTDg3UDVka04tc25kMUY5UkhQRjdvSXhNIn0", "carga": "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJzZWMuaXQuZW52LmR0dS5kayJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", "assinatura":" Jp93M4cl3kwa4Z_vAtJPMFue4GfLE2PA4GQk25FZyn17009Njdk52q_IJLRPmzDM58F_NiDPPvHbdzPIKAP6b_6Wi4yFcDCwvvfT-3RTShkwhe6kilP6THnsBDMM08eCxEES1HpC5GG2SSiJxXZOLGNr02xYg00QKAx8zrZje3nSBCxko2SGhV830Fm6qyZrt_bGyoOMVPF6sP0b-gYxGpVixMWGYdhsMJ6KP15qTPKZZO1d3kALFmNvLH5Smke3VVtpcU46FcbMrTPeyQT36a61VRePVCgQPsfpWghn62vt2VXqfsicSsGxhMjTWdeU 8lHHla0Q0FliNNBZ6DLetg"}'}
2016-04-12 07:10:10,296:INFO:requests.packages.urllib3.connectionpool:Iniciando nova conexão HTTPS (1): acme-v01.api.letsencrypt.org
2016-04-12 07:10:10,562:DEBUG:requests.packages.urllib3.connectionpool:"POST /acme/new-authz HTTP/1.1" 201 780
12-04-2016 07:10:10,565:DEBUG:root:Recebido 2016-04-12 07:10:10,567:DEBUG:acme.client:Storing nonce: '|a\xa9\x11\n\xf4\x97Eu\xc9\x9bpI\xc9\xbc$R\xc6M\xe1\xb5\ xd2\xc9\x84z\x81\xe5\xd97\xb9\xbd\xa0'
2016-04-12 07:10:10,567:DEBUG:acme.client:Resposta recebida 2016-04-12 07:10:10,568:DEBUG:acme.challenges:dns-01 não foi reconhecido, mensagem completa: {u'status': u'pending', u'token': u'hcNVoS5oE2un6UiQUJsI68xbE4-HAFSl6Mpqf5gvCVE', u'type': u'dns-01', u'uri': u'https://acme-v01.api.letsencrypt.org/acme/challenge/Tjv85TyFktAUaDNDehng3JOosWv0MvHIrhztzunumUo/47903459'}
2016-04-12 07:10:10,569:INFO:letsencrypt.auth_handler:Executando os seguintes desafios:
2016-04-12 07:10:10,570:INFO:letsencrypt.auth_handler:tls-sni-01 desafio para sec.it.env.dtu.dk
2016-04-12 07:10:10,854:ERROR:letsencrypt_apache.configurator:Não existe vhost com nome de servidor ou alias de: sec.it.env.dtu.dk. Nenhum vhost foi selecionado. Por favor, especifique os nomes dos servidores na configuração do Apache
2016-04-12 07:10:10,895:DEBUG:letsencrypt.error_handler:Exceção encontrada:
Traceback (última chamada mais recente):
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/auth_handler.py", linha 108, em _solve_challenges
resp = self.auth.perform(self.achalls)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", linha 1555, em perform
sni_response = chall_doer.perform()
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/tls_sni_01.py", linha 78, em perform
addrs = self._mod_config()
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/tls_sni_01.py", linha 100, em _mod_config
achall_addrs = self._get_addrs(achall)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/tls_sni_01.py", linha 119, em _get_addrs
vhost = self.configurator.choose_vhost(achall.domain, temp=True)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", linha 314, em choose_vhost
return self._choose_vhost_from_list(target_name, temp)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", linha 324, em _choose_vhost_from_list
raise errors.PluginError("Nenhum vhost selecionado")
PluginError: Nenhum vhost selecionado
2016-04-12 07:10:10,896:DEBUG:letsencrypt.error_handler:Chamando funções registradas
2016-04-12 07:10:10,896:INFO:letsencrypt.auth_handler:Desafios de limpeza
2016-04-12 07:10:11,899:DEBUG:letsencrypt.main:Saindo de forma anormal:
Traceback (última chamada mais recente):
Arquivo "/root/.local/share/letsencrypt/bin/letsencrypt", linha 11, em
sys.exit(main())
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/main.py", linha 692, em main
return config.func(config, plugins)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/main.py", linha 457, em execução
linhagem, ação = _auth_from_domains(le_client, config, domains)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/main.py", linha 90, em _auth_from_domains
renovação.renew_cert(config, domínios, le_client, linhagem)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/renewal.py", linha 236, em renova_cert
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/client.py", linha 246, em gets_certificate
self.config.allow_subset_of_names)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/auth_handler.py", linha 70, em get_authorizations
resp = self._solve_challenges()
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/auth_handler.py", linha 108, em _solve_challenges
resp = self.auth.perform(self.achalls)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", linha 1555, em perform
sni_response = chall_doer.perform()
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/tls_sni_01.py", linha 78, em perform
addrs = self._mod_config()
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/tls_sni_01.py", linha 100, em _mod_config
achall_addrs = self._get_addrs(achall)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/tls_sni_01.py", linha 119, em _get_addrs
vhost = self.configurator.choose_vhost(achall.domain, temp=True)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", linha 314, em choose_vhost
return self._choose_vhost_from_list(target_name, temp)
Arquivo "/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", linha 324, em _choose_vhost_from_list
raise errors.PluginError("Nenhum vhost selecionado")
PluginError: Nenhum vhost selecionado

@hugo-connery Obrigado pelos dados adicionais, as perguntas de acompanhamento:

Seu arquivo de configuração do virtualhost reside em /etc/httpd/conf.d e o arquivo de configuração que contém o vhost tem outros vhosts nele?

@bret-miller Obrigado pelo tarball de configuração do apache. Investigarei o problema e as mensagens de erro com sua configuração.

No entanto, deve-se notar que o cliente LE espera uma única configuração de virtualhost dentro de um arquivo de configuração, e sua configuração parece ter ambos: e configurações dentro de um arquivo por domínio.

Para melhor compatibilidade a partir de agora, sugiro que você divida os arquivos de configuração em dois: um para a configuração HTTP vhost e outro para o HTTPS.

Como dito acima, continuaremos analisando esse assunto e, no mínimo, trabalhando para garantir que a configuração não seja quebrada.

@bret-miller para referência, este problema é relatado em #1042

Manteremos esse problema em aberto, pois outros na discussão provavelmente têm um problema diferente em mãos.

No meu caso, não estou usando 000-default, mas apenas definimos arquivos conf para cada ferramenta que estou usando. Desde a atualização, também não consigo detectar os diferentes arquivos conf. Ele continua querendo que eu use 000-default e outros arquivos padrão, mas não os arquivos conf reais. Quando eu executo o comando de renovação ele tem um registro dos arquivos conf apropriados mas recorre ao padrão 000 novamente?

@shaneonabike O cliente não salva os caminhos do arquivo de configuração, apenas os domínios. E embora os domínios padrão não tenham ServerName ou ServerAlias ​​definidos, eles correspondem a todos eles. Esse problema provavelmente ocorre porque seus arquivos vhost não estão sendo analisados ​​corretamente.

Eu precisaria obter seu diretório de configuração do apache para poder analisá-lo melhor.

OK. Então, para novos domínios, começarei a criar arquivos separados para os vhosts ssl e não-ssl. Fiz o meu primeiro. O cliente LE ainda não está instalando o certificado na configuração. Enviei os arquivos de log e vhost por e-mail para sudo /home/webmaster/.local/share/letsencrypt/bin/letsencrypt -t --agree-tos --apache --config /home/webmaster/bin/letsencrypt-gcimontreal.ini
ini contém apenas a lista de domínios. Ou seja, uma linha: domains = gcimontreal.ca, www.gcimontreal.ca

Respondi por e-mail, mas acho melhor continuar a discussão aqui:

A parte relevante dos logs, anonimizada:

2016-04-12 16:31:12,671:INFO:letsencrypt_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/domainname-ssl.conf
2016-04-12 16:31:12,672:DEBUG:letsencrypt_apache.configurator:Apache version is 2.4.18
2016-04-12 16:31:12,687:DEBUG:letsencrypt.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/client.py", line 360, in deploy_certificate
    fullchain_path=fullchain_path)
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", line 277, in deploy_cert
    self.enable_site(vhost)
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", line 1385, in enable_site
    os.symlink(vhost.filep, enabled_path)
OSError: [Errno 17] File exists

2016-04-12 16:31:12,687:DEBUG:letsencrypt.error_handler:Calling registered functions
2016-04-12 16:31:12,693:DEBUG:letsencrypt.main:Exiting abnormally:
Traceback (most recent call last):
  File "/home/user/.local/share/letsencrypt/bin/letsencrypt", line 11, in <module>
    sys.exit(main())
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/main.py", line 692, in main
    return config.func(config, plugins)
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/main.py", line 461, in run
    lineage.chain, lineage.fullchain)
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/client.py", line 360, in deploy_certificate
    fullchain_path=fullchain_path)
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", line 277, in deploy_cert
    self.enable_site(vhost)
  File "/home/user/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", line 1385, in enable_site
    os.symlink(vhost.filep, enabled_path)
OSError: [Errno 17] File exists

Infelizmente não consigo reproduzir o problema. Olhando para os logs, parece que o Let's Encrypt pensa que está criando um novo arquivo de configuração, mas na realidade o arquivo já existe e está habilitado. LE falha ao tentar ativar um vhost já ativado.

Você poderia descrever sua configuração antes e depois. Você também estava renovando os domínios ou obtendo o certificado inicial?

O que eu suponho que sua configuração parece antes:

Vhost para HTTP: apache/sites-available/domain.conf -> apache/sites-enabled/domain.conf
Vhost para HTTPS: apache/sites-available/domain-ssl.conf -> apache/sites-enabled/domain-ssl.conf

Então os dois estão ativos antes da execução, certo?

Estou tentando identificar o porquê
a) Let's Encrypt acha que seu site SSL não está ativado, embora esteja ou
b) O link simbólico existe mesmo que o site não esteja ativado

Não tenho certeza de qual era o problema anterior, mas tive que criar o link SSL do domínio em sites habilitados manualmente, então provavelmente foi isso. Eu tenho dividido os arquivos conf para que isso funcione corretamente, e o último que fiz emitiu e instalei seu certificado perfeitamente. Portanto, enquanto a combinação de vhosts de domínio único em um arquivo conf funcionou no cliente LE 0.4.2, não funciona no cliente LE 0.5.0. A resposta é dividi-los todos.

Ainda podemos usar as várias opções -d para um certificado em vez de declarar um certificado para cada arquivo conf?

Significado... posso fazer ./letsencrypt-auto --apache -d beesonabike.com -d www.beesonabike.com -d somethingelse.beesonabike.com

Antes disso funcionava corretamente, mas eu _suspeito_ no meu caso, pelo menos, esse pode ser o motivo pelo qual agora está falhando porque está tentando encontrar o "um" arquivo conf que corresponde a todos esses URLs definidos

@shaneonabike Todos os meus certificados são emitidos com pelo menos o domínio e www.domain. Vários têm uma dúzia ou mais subdomínios neles. No entanto, recentemente mudei de usar -d na linha de comando para criar um arquivo .ini com domains=domain1,domain2,domain3,... e usando -c ini-file na linha de comando. Isso facilita o script do comando ao adicionar um domínio a um certificado existente. Eu sei que funciona com 0.5.0 porque eu usei hoje.

Eu poderia tentar usar o arquivo ini... você achou isso nos documentos?

@shaneonabike Sim, é mencionado nos documentos . Ele também informa mais sobre os parâmetros disponíveis na ajuda da linha de comando. Eu só uso para a lista domains=, mas você pode colocar tudo no arquivo .ini se quiser.

@joohoi Não consigo encontrar suas informações de contato, então não consigo disparar um tarball do seu jeito

Oh, desculpe. Tente [email protected]

@shaneonabike Eu verifiquei sua configuração do apache e parece que seu problema é semelhante - você tem várias definições de VirtualHost por arquivo. Divida sua configuração para ter um único VirtualHost por arquivo e você deve ficar bem.

@hugo-connery @thorstensiefert Se você ainda está tendo problemas (e não é causado por ter vários vhosts em um único arquivo), você poderia fornecer mais algumas informações, por exemplo, o tarball da sua configuração do apache para permitir que eu analise mais sobre isso importam?

@joohoi Posso confirmar que separá-los faz com que funcione perfeitamente (embora essa seja uma mudança desde o último grande lançamento). Isso pode ser documentado em algum lugar, a menos que eu tenha perdido anteriormente.

Para outros usuários serem mais claros:

• É importante separar todas as definições de vhost em arquivos separados. Isso significa que as portas 80 e 443 em arquivos conf separados
• Então, se você tiver um arquivo vhosts como mysite.conf

<VirtualHost *:80>
  ServerAlias www.mysite.com
  ServerName mysite.com
</VirtualHost>
<VirtualHost *:443>
    ServerName mysite.com
    ServerAlias www.mysite.com
</VirtualHost>

Então você quer converter isso para
meusite.conf

<VirtualHost *:443>
    ServerName mysite.com
    ServerAlias www.mysite.com
</VirtualHost>

e 80-meusite.conf

<VirtualHost *:80>
  ServerAlias www.mysite.com
  ServerName mysite.com
</VirtualHost>

Vou ver se consigo dividir as definições de host virtual em separado
arquivos e se isso ajuda.

/Hugo

Ou melhor ainda, coloque isso na documentação de ajuda da ferramenta de linha de comando

Vou dar uma chance.
THX

Am 14.04.2016 às 16:47 schrieb Joona Hoikkala [email protected] :

@hugo-connery @thorstensiefert Se você ainda está tendo problemas (e não é causado por ter vários vhosts em um único arquivo), você poderia fornecer mais algumas informações, por exemplo, o tarball da sua configuração do apache para permitir que eu analise mais sobre isso importam?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

Oi,

Muita melhoria. O certificado foi renovado, instalado e configurado.

Queixou-se de:

Não foi possível adicionar o título

ANOTAÇÕES IMPORTANTES:

• Não foi possível configurar o redirecionamento de aprimoramento para seu servidor,
  no entanto, instalamos seu certificado com sucesso.
• Parabéns! Seu certificado e cadeia foram salvos em
  /etc/letsencrypt/live/sec.it.env.dtu.dk/fullchain.pem. Seu certificado
  expirará em 2016-07-14. Para obter uma nova versão do
  certificado no futuro, basta executar Let's Encrypt novamente.

E as linhas de configuração do certificado também não usam
chain.pem ou fullchain.pem (o que não é um problema, mas eu
observe essas coisas).

Abraço, Hugo

@joohoi eu tentei (https://github.com/letsencrypt/letsencrypt/issues/2776#issuecomment-209979862) e funciona bem para mim.
THX!

Onde colocar a documentação?

Sugiro uma página em letsencrypt.org que fala sobre a estrutura recomendada para definições de vhost em /etc/httpd/conf.d/

Essa página, que deve mostrar uma configuração mínima do servidor com dois sites, pode ser vinculada a partir da página de introdução na seção onde ela discute o Apache.

Em segundo lugar, ele pode ser emitido como uma mensagem informativa se alguém usar letsencrypt-auto --apache.

ou seja, "Use nosso layout de configuração recomendado para hosts virtuais para obter melhores resultados: https://letsencrypt.org/apache-vhost-config.html "

ou equivalente.

Obrigado a todos que contribuíram com o tópico. Estou feliz por ter um modelo de trabalho que posso usar para _todos os meus outros sites e servidores_ :)

/Hugo

@thorstensiefert incrível!

@hugo-connery Acho que o local correto seria na verdade uma notificação que o cliente emite quando se depara com um arquivo vhost com mais de uma definição de VirtualHost. Vou criar um novo problema para isso, porque esse problema é muito longo para ter uma visão rápida do que está acontecendo.

Outra coisa: essa mensagem "Unable to add title" é emitida por reverter, que trata de rollbacks de configuração, e basicamente é impressa quando o reverer não consegue adicionar um ponto de verificação para um arquivo. Pode valer a pena investigar mais, se na próxima execução ainda for exibido, mas eu não me preocuparia com isso a partir de agora.

Motivo: o usuário tem várias configurações de VirtualHost por arquivo. 0.5.0 impõe regras mais rígidas na configuração do vhost, portanto, o cliente não consegue encontrar as configurações corretas do VirtualHost.

Solução: divida as configurações do VirtualHost para um vhost por arquivo.

Acho que esse problema está praticamente resolvido. @hugo-connery Acho que você pode fechar isso por enquanto e abrir um novo para o erro de reversão se você se deparar com ele novamente, está fora do escopo deste problema.

sim. A questão está encerrada.

Fonte do problema (vários vhosts em um arquivo de configuração) identificada e corrigindo isso corrige o problema.

/Hugo

Eu também tive o mesmo problema com a mesma resolução. Meus vhosts HTTP e HTTPS foram definidos no mesmo arquivo de configuração. Separá-los resolveu o problema.

Eu experimentei o mesmo problema e fiquei muito triste ao ver que o suporte para vários vhosts por arquivo de configuração foi removido - e pior ainda, nenhuma mensagem de erro correta foi exibida :(
Meus arquivos de configuração estavam funcionando bem por anos e, pessoalmente, prefiro vários vhosts por configuração.

Tudo estava funcionando bem com vários VHosts por arquivo de configuração, desde que eles não fossem para a mesma porta (ou seja, VHost:80 e VHost:443 no mesmo arquivo de configuração estavam ok, enquanto Vhost:443 + VHost:443 não era suportado).

E agora isso não funciona mais? Por quê?

Isso é muito PITA, pois tenho uma longa lista de arquivos conf para cada subdomínio que combina o VHost 80 e o VHost 443 e agora tenho que dividir todos eles em dois ...

Eu sei que vários HTTPS VHosts por arquivo nunca foram suportados, mas um HTTPS VHost + o HTTP funcionou bem antes. E agora não é mais suportado aparentemente? Para mim isso parece uma regressão...

Caso possa ser útil para outra pessoa, usei um pequeno script bash para me ajudar a dividir meus vários arquivos de configuração:

#!/bin/bash
set -e

NAME=$1

#csplit -f $NAME.conf $NAME.conf '/^<VirtualHost \*:443>$/'
csplit -f $NAME.conf $NAME.conf '/^<IfModule mod_ssl\.c>$/'
mv $NAME.conf00 $NAME-80.conf
mv $NAME.conf01 $NAME-443.conf
a2dissite $NAME.conf
a2ensite $NAME-80.conf
a2ensite $NAME-443.conf

Ele usa o programa csplit (no pacote coreutils no Debian jessie por exemplo) para encontrar um padrão onde o arquivo deve ser dividido.

Dependendo de seus arquivos de configuração, o padrão pode ser /^<VirtualHost \*:443>$/ ou /^<IfModule mod_ssl\.c>$/ ou qualquer outra coisa. (adaptar a linha csplit no script de acordo)

A convenção assumida aqui é que:

• o nome do arquivo original da configuração é mysite.conf
• você chama o script acima como segue ./split_vhosts.sh mysite
• os arquivos resultantes são chamados mysite-80.conf e mysite-443.conf (assumindo que o primeiro VHost no arquivo de configuração original era para a porta 80 e o segundo para a porta 443)
• Ele chama a2dissite mysite.conf para desativar o arquivo conf original
• ele chama a2ensite para cada um dos arquivos divididos.

Agora ainda é seu trabalho verificar se os arquivos resultantes estão corretos e recarregar o apache. Os arquivos de configuração originais não são excluídos, você pode querer fazer isso manualmente depois de ter certeza de que tudo funciona.

A correção para isso foi enviada hoje. Por favor, abra um novo ticket se você estiver vendo esse problema no Certbot 0.6.0!