Debido a varios procesos, ahora casi todo el mundo ha oído hablar de la sustitución de importaciones. En particular, ahora el producto importado de MS Exchange está siendo reemplazado activamente por ruso nativo sin un solo clavo * Communigate Pro. Si mis colegas encuentran el tiempo, creo que pueden contar mucho sobre los clústeres, la carga y la migración, pero quiero contarles una sangre escalofriante, pero una historia mucho menos extensa sobre las características nacionales de la renovación de certificados en este maravilloso producto.
En realidad, un breve trasfondo. Tengo una pequeña computadora portátil en un armario en el que hasta hace poco el servidor de correo estaba funcionando en un montón de Windows + hMailServer. Naturalmente, en virtud de la sustitución de importaciones, quería conocer a Communigate Pro más de cerca, afortunadamente, es muy modesto en requisitos y es gratuito
en algunas escalas :
Proporcionamos la versión completa de CommuniGate Pro de forma gratuita para cinco usuarios con fines de prueba y para su uso en pequeños proyectos (empresas).
El conocimiento puede iniciarse
en la sección Acerca de nosotros . Es muy claramente visible allí que en 1997 se alcanzó el hito "Primera confianza", los vendedores Stalker, Inc. aprendieron a escribir la palabra "Lanzamiento" solo en 2004, y aún no han podido hacer materiales de marketing en ruso para el sitio ruso.
La instalación del producto (lo instalé en CentOS 7) no causó ninguna dificultad, aproveché esta oportunidad, puse CertBot allí, certifiqué los certificados de Let's Encrypt y, en general, todo comenzó.
Después de 3 meses, los certificados expiraron según lo planeado y era hora de cambiarlos.
Luego descubrí que Windows trajo un reemplazo muy inesperado para el cliente Telnet:
La regeneración de claves usando las herramientas CertBot fue aburrida, tal vez me complació el servidor dns1.yandex.ru, que durante una hora proporcionó el tac-record obsoleto o actualizado _acme-challenge, por lo que pude generar certificados solo en el tercer intento .
Y entonces comenzó la magia.
El servidor Communigate no tiene la capacidad de reemplazar el par de claves por uno nuevo a través de la interfaz, primero debe eliminar el par de claves anterior:
Como administrador de host localhost consciente, activé la autenticación solo a través de SSL y me olvidé de ello de forma segura, por lo que después de eliminar el par de claves, el servidor se negó a comunicarse conmigo:
Apagué el servidor paranoico agregando esta línea al archivo /var/CommuniGate/Accounts/postmaster.macnt/account.settings:
RequireAPOP = NO;pero el sedimento, por supuesto, permaneció. Naturalmente, quería hacer un
botón para mí mismo el script para reemplazar el par de claves con una ejecución de este script, y no caminar en círculos de acuerdo con la configuración del usuario.
Las herramientas de automatización en Communigate están presentes en hasta
cuatro interfaces : comunicación de texto a través de conexión TCP (PWD), módulo CLI.pm pearl (CG / PL), solicitudes web simples y XIMSS.
Por varias razones (principalmente pereza, por supuesto), elegí las solicitudes web.
Desde el principio, algo salió mal:
[root@mx ~]
Resultó que leí la documentación sin prestar atención, tenía que hacerlo así:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings' {CAChain=[---];CertificateType=YES;ClientCertCA="Let's Encrypt Authority X3";ClientIPs="";DKIMenabled=YES;DKIMkey=[---DKIM];DKIMselector=dkim;DomainComment="";IPMode="All Available";PrivateSecureKey=[---];SecureCertificate=[--];TrustedCertificates=();}
Entonces algo salió mal otra vez:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings&domainName=test' {CAChain=[---];CertificateType=YES;ClientCertCA="Let's Encrypt Authority X3";ClientIPs="";DKIMenabled=YES;DKIMkey=[---DKIM];DKIMselector=dkim;DomainComment="";IPMode="All Available";PrivateSecureKey=[---];SecureCertificate=[--];TrustedCertificates=();}
Este giro de los acontecimientos me dejó perplejo y apoyé
al vendedor .
Como un anuncio publicitario.
Sí, tienen una sala de chat. Y los expertos incluso responden en eso. Incluso sin ninguna suscripción corporativa.
Resultó que la solicitud http no comprende los parámetros nombrados. Solo posicional, solo hardcore:
[root@mx ~]
El dominio de prueba, de acuerdo con su nombre, es un dominio de prueba, por lo que no hay configuraciones en él.
Luego presenté cómo incrustar un certificado en la URL y decidí que tenía que hacer algo al respecto. Por ejemplo, use la solicitud POST de una persona sana en lugar de la solicitud GET del fumador para la transferencia de datos:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
Bueno, hasta ahora todo va según lo planeado.
Let's Encrypt guarda sus tesoros en el directorio /etc/letsencrypt/live/domain.my/ desde allí y los obtendremos.
Un poco más arriba en la solicitud getdomainsettings, vi que la clave privada se encuentra en el campo PrivateSecureKey, y lo que es más, se encuentra allí con el encabezado y el pie de página mordidos, y todo lo demás se combina en una línea. Intentemos importarlo.
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode "command=updatedomainsettings test {PrivateSecureKey=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'`];}" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title> domain.my</title> <link rel="stylesheet" href="/SkinFiles/domain.my/Pronto/style.css" type="text/css" /> <meta http-equiv="x-dns-prefetch-control" content="off" /> <meta name="referrer" content="no-referrer" /> </head> <body background="/SkinFiles/domain.my/Pronto/bodybgcolor.gif"> <form method="post" enctype="multipart/form-data"> <input type="hidden" name="FormCharset" value="utf-8" /> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr><td height="25"> </td></tr> <tr valign="middle"><td align="center" bgcolor="#ffcccc" class="externalError">private key data is corrupted</td></tr> </table> </form> </body> </html> [root@mx ~]#
Uh ... Bueno ... no esperaba esto.
Pensé que era un certbot, en lugar de una clave privada, resbalé algo extraño, saqué el contenido del archivo:
[root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- [root@mx ~]#
e insertado a través de la interfaz web:
De repente, todo salió bien:
Eliminé la clave e intenté importarla nuevamente con una solicitud HTTP. No ocurrió ningún milagro,
los datos de clave privada resultaron estar todavía
corruptos .
Perplejo, volví a visitar al
conejo de soporte técnico. El soporte técnico dijo que debe morder el encabezado y el pie de página del archivo de clave privada y combinar el resultado en una línea. Cuando pregunté si hice todo bien con este comando:
grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
El oficial de soporte respondió que no era un experto en grep y que no lo sabía.
En el proceso de diálogo, descubrí que si extraigo la clave anterior con la solicitud getdomainsettings, la solicitud HTTP la importa normalmente, decidí que mi grep | tr muerde algo superfluo y se despide de la sala de chat de Stalker.
Sin embargo, no fue tan simple. Después de limpiar la clave privada manualmente, descubrí que no se importó de todos modos.
Aquí me metí en un callejón sin salida final.
Después de sufrir este fenómeno, decidí escupir y hacer todo manualmente, importé la clave privada a través de la interfaz web ... Y finalmente hice una solicitud de configuración de dominio. De repente, resultó que Communigate no me devolvía lo que le había dado de comer. Además, la clave privada Let's Encrypt después de la limpieza tenía 1624 caracteres de largo, y lo que Communigate me mostró tenía solo 1592 de longitud.
No estaba listo para tal giro y subí a OpenSSL. El primer disparo dio en el blanco:
[root@mx ~]# openssl rsa -in /etc/letsencrypt/live/domain.my/privkey.pem writing RSA key -----BEGIN RSA PRIVATE KEY----- , , -----END RSA PRIVATE KEY----- [root@mx ~]#
Hurra, misión cumplida.
No necesitábamos bailes con certificados, solo muerden un encabezado con un pie de página y las sobras se combinan en una línea.
Total, el resultado final se ve así para mí:
curl --user postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode "command=updatedomainsettings domain.my {SecureCertificate=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/cert.pem | tr -d '\n'`];PrivateSecureKey=[`openssl rsa -in /etc/letsencrypt/live/domain.my/privkey.pem 2> /dev/null | grep -v '\-\-' | tr -d '\n'`];CAChain=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/chain.pem | tr -d '\n'`];}"
Como unix-shell no es mi entorno nativo, agradeceré enormemente las optimizaciones.
Bueno, y nunca se sabe, de repente alguien me necesitará, no podría googlear esto.
* las uñas en Communigate Pro realmente no se encontraron