En raison de divers processus, presque tout le monde a maintenant entendu parler d'une chose telle que la substitution des importations. En particulier, le produit MS Exchange importé est désormais activement remplacé par le russe natif sans un seul clou * Communigate Pro. Si mes collègues trouvent le temps, je pense qu'ils peuvent en dire beaucoup sur les clusters, les charges de travail et la migration, mais je veux vous raconter un sang-froid, mais une histoire beaucoup moins complète sur les caractéristiques nationales du renouvellement des certificats dans ce merveilleux produit.
En fait, un bref historique. J'ai un petit ordinateur portable dans un placard sur lequel, jusqu'à récemment, le serveur de messagerie bourdonnait dans un tas de Windows + hMailServer. Naturellement, en raison de la substitution des importations, j'ai voulu mieux connaître Communigate Pro, heureusement, il est très modeste en termes d'exigences et est gratuit
à certaines échelles :
Nous fournissons la version complète de CommuniGate Pro gratuitement pour cinq utilisateurs à des fins de test et pour une utilisation dans de petits projets (entreprises).
La connaissance peut être démarrée
dans la section À propos de nous . Il est très clair là-bas qu'en 1997, le jalon «First reliase» a été atteint, les spécialistes du marketing Stalker, Inc n'ont appris à écrire le mot «Release» qu'en 2004, et ils n'ont toujours pas été en mesure de produire du matériel de marketing en russe pour le site russe.
L'installation du produit (je l'ai installé sur CentOS 7) n'a pas posé de problème, saisissant cette opportunité, j'y ai mis CertBot, vissé des certificats de Let's Encrypt et, en général, tout a démarré.
Après 3 mois, les certificats ont expiré comme prévu et il était temps de les changer.
Ensuite, j'ai découvert que Windows apportait un remplacement très inattendu pour le client Telnet:
La régénération des clés à l'aide des outils CertBot était ennuyeuse, j'étais peut-être satisfait du serveur dns1.yandex.ru, qui, pendant une heure, a donné soit le tac-record _acme-challenge obsolète ou mis à jour, à cause duquel je n'ai pu générer des certificats qu'à la troisième tentative .
Et puis la magie a commencé.
Le serveur Communigate n'a pas la possibilité de remplacer la paire de clés par une nouvelle via l'interface, vous devez d'abord supprimer l'ancienne paire de clés:
En tant qu'administrateur hôte localhost conscient, j'ai activé l'authentification uniquement par SSL et l'ai oublié en toute sécurité, donc après avoir supprimé la paire de clés, le serveur a refusé de communiquer avec moi:
J'ai désactivé le serveur paranoïaque en ajoutant cette ligne au fichier /var/CommuniGate/Accounts/postmaster.macnt/account.settings:
RequireAPOP = NO;mais, bien sûr, les sédiments sont restés. Naturellement, je voulais créer un
bouton pour moi-même le script pour remplacer la paire de clés par une seule exécution de ce script lui-même, et ne pas tourner en rond selon les paramètres de l'utilisateur.
Les outils d'automatisation de Communigate sont présents dans jusqu'à
quatre interfaces : communication de texte via une connexion TCP (PWD), module perle CLI.pm (CG / PL), requêtes Web simples et XIMSS.
Pour diverses raisons (principalement la paresse, bien sûr), j'ai choisi des requêtes web.
Dès le début, quelque chose s'est mal passé:
[root@mx ~]
En fin de compte, j'ai lu la documentation avec attention, je devais le faire comme ceci:
[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=();}
Puis quelque chose s'est mal passé:
[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=();}
J'ai été perplexe face à cette tournure des événements et je me suis tourné vers
le fournisseur .
Comme une publicité.
Oui, ils ont une salle de chat. Et les experts y répondent même. Même sans abonnement d'entreprise.
En fait, la requête http ne comprend pas les paramètres nommés. Seulement positionnel, seulement hardcore:
[root@mx ~]
Le domaine de test, conformément à son nom, est un domaine de test, il n'y a donc aucun paramètre.
Ensuite, j'ai présenté comment j'intégrerai un certificat dans l'URL et j'ai décidé que je devais faire quelque chose. Par exemple, utilisez la demande POST d'une personne en bonne santé au lieu de la demande GET du fumeur pour le transfert de données:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
Eh bien, jusqu'à présent, tout se déroule comme prévu.
Let's Encrypt conserve ses trésors dans le répertoire /etc/letsencrypt/live/domain.my/ à partir de là et nous les obtiendrons.
Un peu plus haut dans la demande getdomainsettings, j'ai vu que la clé privée se trouve dans le champ PrivateSecureKey, et qui plus est, elle se trouve avec un en-tête et un pied de page mordus, et tout le reste est fusionné en une seule ligne. Essayons de l'importer.
[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 ~]#
Euh ... Eh bien ... je ne m'attendais pas à ça.
Je pensais que c'était un certbot, au lieu d'une clé privée, j'ai glissé quelque chose d'étrange, j'ai retiré le contenu du fichier:
[root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- [root@mx ~]#
et inséré via l'interface web:
Du coup, tout s'est bien passé:
J'ai supprimé la clé et j'ai essayé de l'importer à nouveau avec une requête HTTP. Aucun miracle ne s'est produit,
les données de clé privée se sont
avérées encore
corrompues .
Perplexe, je suis de nouveau allé rendre visite au
lapin d' assistance technique. Le support technique a déclaré que vous devez mordre l'en-tête et le pied de page du fichier de clé privée et combiner le résultat sur une seule ligne. Quand j'ai demandé si j'avais tout fait correctement avec cette commande:
grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
L'officier de soutien a répondu qu'il n'était pas un expert en grep et ne savait pas.
Au cours du dialogue, j'ai constaté que si je retirais l'ancienne clé avec la demande getdomainsettings, la demande HTTP l'importait normalement, j'ai décidé que mon grep | tr mord quelque chose de superflu et dit au revoir à la salle de chat de Stalker.
Mais ce n'était pas si simple. Après avoir nettoyé la clé privée manuellement, j'ai constaté qu'elle n'était pas importée de toute façon.
Ici, j'ai erré dans une impasse finale.
Ayant souffert de ce phénomène, j'ai décidé de cracher et de tout faire manuellement, d'importer la clé privée via l'interface web ... Et enfin, j'ai fait une requête getdomainsettings. Du coup, il s'est avéré que Communigate ne me rendait pas ce que je lui avais donné à manger. De plus, la clé privée Let's Encrypt après le nettoyage comptait 1624 caractères et ce que Communigate m'a montré n'était que de 1592.
Je n'étais pas prêt pour un tel virage et suis monté dans openssl. Le premier coup a touché la cible:
[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 ~]#
Hourra, mission accomplie.
Nous n'avions pas besoin de danses avec certificats, ils mordaient juste une tête avec un pied de page et les restes étaient combinés sur une seule ligne.
Au total, le résultat final ressemble à ceci pour moi:
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'`];}"
Comme unix-shell n'est pas mon environnement natif, j'apprécierai grandement les optimisations.
Eh bien, et on ne sait jamais, tout à coup quelqu'un aura besoin de moi, je ne pourrais pas google ça.
* les clous dans Communigate Pro sont vraiment introuvables