puppetca nunca retorna nada

Question

Oi: Estou tentando configurar o Puppet no Ubuntu e, estranhamente, nunca consigo gerar um certificado porque meu servidor nunca mostra solicitações de certificados pendentes.

Colocado de forma diferente, no servidor estou executando o puppetmasterd e no cliente eu consigo conectar ao servidor, mas o cliente continua imprimindo

notice: Did not receive certificate
warning: peer certificate won't be verified in this SSL session

e, no entanto, o servidor nunca vê a solicitação

mrisher@lab2$ puppetca --list                        
[nothing shows up]
mrisher@lab2$ puppetca --sign clientname.domain.com
clientname.domain.com
err: Could not call sign: Could not find certificate request for clientname.domain.com

Edit: Houve uma sugestão de que o autosign estava acontecendo, mas isso não parece ser. Não há arquivo autosign.conf e, quando executo puppetmasterd --no-daemonize -d -v , recebo a seguinte saída:     info: não foi possível encontrar o certificado para 'clientname.domain.com' toda vez que o cliente diz     aviso: não recebeu certificado

Eu verifiquei os certificados no servidor e parece não haver nenhum:

mrisher@lab2:~$ puppetca --list --all
mrisher@lab2:~$ sudo puppetca --list --all
+ lab2.domain.com          // this is the server (master)
mrisher@lab2:~$ sudo puppetca --list      
[blank line]
mrisher@lab2:~$

Nota: Esta é a maior parte da execução da instalação padrão do Ubuntu, se isso der pistas.

Obrigado por qualquer ajuda lá fora.

EDIT Parece que isso ocorreu devido à execução inconsistente de puppetd como usuários diferentes. Por razões que eu realmente não entendo para um daemon, o fantoche armazena algumas de suas configurações - incluindo os certificados - em ~ / .puppet em vez de um diretório central como /var/lib/puppet , e, portanto, importa se você está testando como você mesmo versus sudo.

    

Answer 1

Sua solicitação de certificado chegou ao servidor? (Use o valor de puppetmasterd --configprint ssldir onde eu escrevi $ssldir aqui)

Em $ssldir/ca , deve haver uma estrutura de diretórios como esta:

   private/
   requests/
   serial
   signed/

E abaixo de requests , se a solicitação do seu cliente realmente tiver sido criada, você verá um arquivo chamado clientname.domain.com.pem . Se estiver lá e precisar de assinatura, você pode apontar o puppetca diretamente, especificando puppetca --ssldir=/path/to/ssldir --sign clientname.domain.com ; se NÃO estiver lá, o upload do CSR do cliente pode ter falhado silenciosamente. Uma solução fácil (e segura) é usar puppetca --generate clientname.domain.com no seu puppetmaster para fazer um par de chaves e um certificado assinado para os clientes. Uma solução fácil e insegura é ativar o auto-preenchimento para o seu domínio, largando '* .domain.com' no autosign.conf no $confdir do puppetmaster.

    

Answer 2

Este é, na verdade, o tipo de comportamento que você verá se o autosigning estiver ativado. Você pode ver o conteúdo de /etc/puppet/autosign.conf para ver exatamente para quais domínios isso está habilitado. Por exemplo, suponha que o arquivo continha o seguinte:

*.example.com
192.168.0.0/24

Isso significaria que quaisquer certificados provenientes de um nome de host sob a árvore example.com ou do bloco de endereços 192.168.0.0/24 seriam assinados pela puppetca sem qualquer interação administrativa.

Você pode ver todos dos certificados, assinados ou não, emitindo o comando

/usr/sbin/puppetca --list --all

    

Answer 3

Tente excluir uma incompatibilidade de nome de certificado mestre de fantoches.

No nó do agente:

$ sudo puppetd --configprint server

No mestre:

$ sudo puppetca --print lab2.domain.com

... e procure por essas linhas na saída:

...
Subject: CN={A hostname}
...
X509v3 Subject Alternative Name: 
DNS:{a hostname}, DNS:{another hostname}, {etc.}

Se o nome do host que o agente estiver usando para contatar o mestre IS um nome de host válido para o mestre, mas ISN'T no "nome comum do assunto" (certname) ou campos "subject alternative name" (certdnsnames) no certificado SSL do mestre, você estará em um mundo de dor.

(Se esse for o problema, altere puppet.conf no agente para apontar para um certname ou certdnsname de trabalho para o puppet master, ou pare o puppet master, edite o puppet.conf para ter o certname e certdnsnames que você quer, retire seu ssldir ( puppetmaster --configprint ssldir ) e reinicie o master.)

    

Answer 4

Eu queria entrar em contato para explicar uma coisa que encontrei: digamos que estava no meio do caminho (onde o cliente podia entrar em contato com o mestre dos fantoches, mas agora as solicitações de certificado não aparecem mais). No meu caso, eu já estava no meio do caminho, mas não consegui nem SSH do cliente para o mestre de marionetes. Ímpar. Nesse caso, tive que passar pelos mesmos diretórios ssl (acima) no site do cliente para remover os certificados do cliente e do mestre de marionetes e limpar os arquivos ca para o mestre de marionetes. No puppet-master eu tive que fazer a ação de espelho de remover os rastros do certificado do cliente de todos os diretórios, e a listagem do cliente no arquivo /var/lib/puppet/ssl/ca/inventory.txt.

Depois de fazer isso e reiniciar os dois, eu pude ver a solicitação. A questão era que o puppet-master já tinha uma lista de certificados válidos para o cliente no arquivo inventory.txt no diretório / var / lib / puppet / ssl / ca, mas eu havia limpado ou excluído o certificado real. Meu syslog no mestre de marionetes mostrava: "Certificado não encontrado para o host ...", o que significa que ele sabia que um estava no inventário, mas o certificado real estava em "ordem inversa" metafórica ou simplesmente ausente.

Portanto, limpe os certificados antigos para o ca e o mestre dos fantoches no lado do cliente. Em seguida, remova a listagem cert e cert no inventory.txt, e isso deve funcionar.