O hostname do Puppet não corresponde ao certificado do servidor

Question

Estou tentando configurar uma VM do Ubuntu com um fantoche instalado para poder testar localmente nossa configuração de produção. Eu estou tendo problemas para fazer com que marionetes e marionetes conversem uns com os outros. Deixe-me levá-lo através dos meus passos. (O hostname do servidor é um FQDN do formato "web1.xxx.xxx.net").

Então, primeiramente, eu limpo todos os arquivos pem (exceto os pems da CA, é claro) do diretório /etc/puppet/ssl para que eu possa fazer um novo começo. puppetca --list não retorna resultados.

Então, eu corro puppetd --test para gerar um CSR para o puppetmaster. puppetca --list agora inclui meu hostname ("web1.xxx.xxx.net").

Em seguida, corro puppetca --sign web1.xxx.xxx.net . Agora puppetca --list está vazio novamente - tudo está funcionando bem até agora.

Por fim, corro puppetd --test novamente. Eu recebo a seguinte saída:

err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Listar o conteúdo do diretório /etc/puppet/ssl mostra arquivos PEM com o nome do servidor correto, que corresponde ao meu hostname . Alguém tem alguma idéia sobre como atacar esse problema?

    

Answer 1

O erro ocorre porque o cliente, por padrão, conecta-se ao nome do host do servidor 'puppet', mas o certificado apresentado não possui 'puppet' como assunto ou como um atributo SubjectAltName.

Para corrigir isso, você pode (escolher um):

1. em vez de inicializar o certificado do seu puppetmaster executando puppetd , inicialize-o executando puppetmasterd - isso fará com que o nome do sujeito do certificado inclua "fantoche".

2. em vez de deixar as coisas ao acaso, você pode usar puppetca --generate --certdnsnames puppet:puppet.mydomain.com web1.xx.xx.xx.net - a opção certdnsnames especifica uma lista de SubjectAltNames que será incluída no certificado; ele deve ter uma lista separada por dois-pontos de qualquer nome que um cliente usaria para entrar em contato com o servidor.

3. em vez de executar apenas puppetd --test no cliente, execute puppetd --test --server=web1.xx.xx.xx.net para que o nome do servidor ao qual o cliente se conecta seja aquele que realmente existe no certificado apresentado pelo servidor.

Confira a excelente entrada do blog da masterzen para mais soluções de problemas: Puppet SSL Explained

    

Answer 2

Você verificou o arquivo de log do puppetmaster? Eu encontrei o mesmo problema e descobri que o servidor registra as informações do certificado:

[2012-02-28 16:21:09] INFO  
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=ca
        Validity
            Not Before: Feb 26 16:32:46 2012 GMT
            Not After : Feb 24 16:32:46 2017 GMT
        Subject: CN=ubuntu.localdomain

O campo Assunto mostra que o CN é "ubuntu.localdomain", então eu executei o fantoche fazendo:

puppetd -t --server=ubuntu.localdomain --fqdn=myfqdn

Espero que isso ajude: -)

    

Answer 3

Além do que o Pau respondeu, eu gostaria de destacar que você pode inspecionar o certificado do mestre de fantoche usando:

openssl x509 -text -in /var/lib/puppet/ssl/certs/<hostname_of_puppet_master>

Depois, certifique-se de usar exatamente o mesmo nome de host quando do cliente:

puppetd --server <hostname_of_puppet_master> <etc>

    

Answer 4

Ambos os servidores são capazes de resolver um ao outro? Meu palpite é que, desde que você está VMing, você pode estar faltando a resolução do nome. Se você não usar o DNS para permitir que os servidores resolvam um ao outro, será necessário adicionar entradas ao seu arquivo /etc/hosts nos dois servidores.

O Puppet exige que os nomes de host sejam resolvidos nos IPs corretos, sem isso você receberá o erro que você mencionou. Talvez seja necessário recriar certificados depois de fazer isso. Ambas as máquinas devem poder pingar cada uma pelo nome do host.

Outra coisa a ter cuidado com as VMs é que você sincroniza os horários nos servidores. Se você não o fizer, é provável que os certificados sejam inválidos.