El nombre de host de Puppet no coincide con el certificado del servidor

Estoy tratando de configurar una máquina virtual Ubuntu con una marioneta instalada para poder probar localmente nuestra configuración de producción. Tengo problemas para hacer que puppetmaster y puppet hablen entre ellos. Déjame llevarte a través de mis pasos. (El servidor hostnamees un FQDN con el formato "web1.xxx.xxx.net").

En primer lugar, borro todos los archivos pem (excepto los pems de CA, por supuesto) del /etc/puppet/ssldirectorio para poder comenzar de nuevo. puppetca --listno devuelve resultados

Luego, corro puppetd --testpara generar una CSR para el titiritero. puppetca --listahora incluye mi nombre de host ("web1.xxx.xxx.net").

Entonces corro puppetca --sign web1.xxx.xxx.net. Ahora puppetca --listestá vacío de nuevo, todo funciona bien hasta ahora.

Por último corro de puppetd --testnuevo. Me sale el siguiente resultado:

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 el contenido del /etc/puppet/ssldirectorio muestra archivos PEM con el nombre de servidor correcto, que coincide con mi hostname. ¿Alguien tiene alguna idea sobre cómo atacar este problema?

El error se debe a que el cliente se conecta de manera predeterminada al nombre de host del servidor 'puppet' pero el certificado presentado no tiene 'puppet' como sujeto o como un atributo SubjectAltName.

Para solucionarlo, puedes (elige uno):

1. en lugar de inicializar su certificado de titiritero ejecutando puppetd, inicialícelo ejecutando puppetmasterd; esto hará que el nombre del sujeto del certificado incluya "puppet".

2. en lugar de dejar las cosas al azar que puede usar puppetca --generate --certdnsnames puppet:puppet.mydomain.com web1.xx.xx.xx.net: la opción certdnsnames especifica una lista de SubjectAltNames que se incluirán en el certificado; debería tener una lista separada por dos puntos de cualquier nombre que un cliente usaría para contactar al servidor.

3. en lugar de simplemente ejecutarse puppetd --testen el cliente, ejecute de puppetd --test --server=web1.xx.xx.xx.netmanera que el nombre del servidor al que se conecta el cliente sea uno que realmente exista en el certificado presentado por el servidor.

Echa un vistazo a la excelente entrada de blog de masterzen para más resolución de problemas: Puppet SSL explicado

¿Revisaste el archivo de registro de puppetmaster? Encontré el mismo problema y descubrí que el servidor registra la información del 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

El campo Asunto muestra que el CN ​​es "ubuntu.localdomain", por lo que ejecuté la marioneta haciendo:

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

Espero que esto ayude :-)

Además de lo que Pau respondió, me gustaría resaltar que puede inspeccionar el certificado de titiriteros usando:

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

Luego, asegúrese de usar exactamente el mismo nombre de host cuando proviene del cliente:

puppetd --server <hostname_of_puppet_master> <etc>

¿Ambos servidores pueden resolverse entre sí? Supongo que, dado que está utilizando VM, es posible que le falte la resolución del nombre. Si no usa DNS para permitir que los servidores se resuelvan entre sí, debe agregar entradas a su /etc/hostsarchivo en ambos servidores.

Puppet requiere que los nombres de host se resuelvan en las IP correctas, sin esto obtendrá el error que mencionó. Es posible que deba volver a crear certificados después de hacer esto. Ambas máquinas deberían poder hacer ping a cada una por nombre de host.

Otra cosa a tener en cuenta con las máquinas virtuales es que sincroniza los tiempos en los servidores. Si no lo hace, es probable que los certificados no sean válidos.