Aufgrund verschiedener Prozesse hat mittlerweile fast jeder von einer Importsubstitution gehört. Insbesondere wird das importierte MS Exchange-Produkt jetzt aktiv durch Russisch ohne einen einzigen Nagel ersetzt * Communigate Pro. Wenn meine Kollegen die Zeit finden, können sie meiner Meinung nach viel über Cluster, Laden und Migration erzählen, aber ich möchte Ihnen ein erschreckendes Blut erzählen, aber eine viel weniger ausführliche Geschichte über die nationalen Merkmale der Erneuerung von Zertifikaten in diesem wunderbaren Produkt.
Eigentlich ein kurzer Hintergrund. Ich habe einen kleinen Laptop in einem Schrank, auf dem bis vor kurzem der Mailserver in einer Reihe von Windows + hMailServer summte. Natürlich wollte ich Communigate Pro aufgrund der Importsubstitution näher kennenlernen, zum Glück sind die Anforderungen sehr bescheiden und
in einigen Maßstäben kostenlos:
Wir stellen die Vollversion von CommuniGate Pro für fünf Benutzer kostenlos zu Testzwecken und zur Verwendung in kleinen Projekten (Unternehmen) zur Verfügung.
Die Bekanntschaft kann
im Abschnitt Über uns gestartet werden. Dort ist sehr deutlich zu erkennen, dass 1997 der Meilenstein „First Reliase“ erreicht wurde, die Vermarkter Stalker, Inc erst 2004 gelernt haben, das Wort „Release“ zu schreiben, und dass sie noch immer keine russischsprachigen Marketingmaterialien für die russische Website erstellen konnten.
Die Installation des Produkts (ich habe es unter CentOS 7 installiert) verursachte keine Schwierigkeiten. Bei dieser Gelegenheit habe ich CertBot dort abgelegt, Zertifikate von Let's Encrypt verschraubt und im Allgemeinen alles gestartet.
Nach 3 Monaten liefen die Zertifikate wie geplant ab und es war Zeit, sie zu ändern.
Dann entdeckte ich, dass Windows einen sehr unerwarteten Ersatz für den Telnet-Client brachte:
Die Schlüsselregenerierung mit CertBot-Tools war langweilig. Ich war vielleicht zufrieden mit dem Server dns1.yandex.ru, der eine Stunde lang entweder die veraltete oder die aktualisierte tac-record _acme-Herausforderung ausgab, aufgrund derer ich erst beim dritten Versuch Zertifikate generieren konnte .
Und dann begann die Magie.
Der Communigate-Server kann das Schlüsselpaar über die Schnittstelle nicht durch ein neues ersetzen. Sie müssen zuerst das alte Schlüsselpaar löschen:
Als bewusster localhost-Hostadministrator habe ich die Authentifizierung nur über ssl aktiviert und sie sicher vergessen. Nach dem Löschen des Schlüsselpaars weigerte sich der Server, mit mir zu kommunizieren:
Ich habe den paranoiden Server gelöscht, indem ich diese Zeile zur Datei /var/CommuniGate/Accounts/postmaster.macnt/account.settings hinzugefügt habe:
RequireAPOP = NO;aber Sediment blieb natürlich zurück. Natürlich wollte ich mir selbst eine
Schaltfläche für das Skript erstellen, um das Schlüsselpaar durch eine Ausführung dieses Skripts selbst zu ersetzen und nicht gemäß den Benutzereinstellungen im Kreis zu laufen.
Die Automatisierungstools in Communigate sind in bis zu
vier Schnittstellen vorhanden : Textkommunikation über TCP-Verbindung (PWD), CLI.pm-Perlenmodul (CG / PL), einfache Webanforderungen und XIMSS.
Aus verschiedenen Gründen (natürlich meistens Faulheit) habe ich mich für Webanfragen entschieden.
Von Anfang an ging etwas schief:
[root@mx ~]
Wie sich herausstellte, las ich die Dokumentation unaufmerksam, ich musste es so machen:
[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=();}
Dann ging wieder etwas schief:
[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=();}
Ich war verwirrt über diese Wendung der Ereignisse und
unterstützte den Verkäufer .
Als Werbung.
Ja, sie haben einen Chatraum. Und Experten antworten sogar darauf. Auch ohne Firmenabonnement.
Wie sich herausstellte, versteht die http-Anfrage die genannten Parameter nicht. Nur positionell, nur hardcore:
[root@mx ~]
Die Testdomäne ist in voller Übereinstimmung mit ihrem Namen eine Testdomäne, daher sind keine Einstellungen darin enthalten.
Dann stellte ich vor, wie ich ein Zertifikat in die URL einbetten werde, und entschied, dass ich etwas dagegen tun muss. Verwenden Sie beispielsweise die POST-Anforderung einer gesunden Person anstelle der GET-Anforderung des Rauchers zur Datenübertragung:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
Bisher läuft alles nach Plan.
Let's Encrypt bewahrt seine Schätze von dort im Verzeichnis /etc/letsencrypt/live/domain.my/ auf und wir werden sie erhalten.
Etwas höher in der Anforderung getdomainsettings habe ich gesehen, dass der private Schlüssel im Feld PrivateSecureKey liegt, und außerdem liegt er dort mit gebissener Kopf- und Fußzeile, und alles andere wird in einer Zeile zusammengeführt. Versuchen wir es zu importieren.
[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 ~]#
Äh ... Nun ... das habe ich nicht erwartet.
Ich dachte, es sei ein Certbot, statt eines privaten Schlüssels habe ich etwas Seltsames herausgerutscht und den Inhalt der Datei herausgezogen:
[root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- [root@mx ~]#
und über das Webinterface eingefügt:
Plötzlich ging alles gut:
Ich habe den Schlüssel gelöscht und versucht, ihn mit einer HTTP-Anfrage erneut zu importieren. Es geschah kein Wunder,
private Schlüsseldaten erwiesen sich immer noch als
beschädigt .
Verblüfft besuchte ich erneut das
Kaninchen des technischen Supports. Der technische Support sagte, dass Sie die Kopf- und Fußzeile aus der privaten Schlüsseldatei beißen und das Ergebnis in einer Zeile kombinieren müssen. Als ich fragte, ob ich mit diesem Befehl alles richtig gemacht habe:
grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
Der Support-Mitarbeiter antwortete, dass er kein Experte für Grep sei und es nicht wisse.
Während des Dialogs stellte ich fest, dass, wenn ich den alten Schlüssel mit der Anforderung getdomainsettings herausziehe, die HTTP-Anforderung ihn normal importiert, ich entschied, dass mein grep | tr beißt etwas Überflüssiges heraus und verabschiedet sich von Stalkers Chatroom.
Es war jedoch nicht so einfach. Nachdem ich den privaten Schlüssel manuell bereinigt hatte, stellte ich fest, dass er sowieso nicht importiert wurde.
Hier bin ich in eine letzte Sackgasse geraten.
Nachdem ich unter diesem Phänomen gelitten hatte, entschied ich mich, alles manuell zu spucken und zu tun, importierte den privaten Schlüssel über die Weboberfläche ... Und schließlich stellte ich eine Anfrage für getdomainsettings. Plötzlich stellte sich heraus, dass Communigate nicht zu mir zurückkehrte, was ich ihm gefüttert hatte. Darüber hinaus war der private Schlüssel "Let's Encrypt" nach der Bereinigung 1624 Zeichen lang, und Communigate zeigte mir, dass er nur 1592 Zeichen lang war.
Ich war nicht bereit für eine solche Wende und stieg in openssl. Der erste Schuss traf das Ziel:
[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, Mission erfüllt.
Wir brauchten keine Tänze mit Zertifikaten, sie beißen nur eine Kopfzeile mit einer Fußzeile und die Reste werden in einer Zeile zusammengefasst.
Insgesamt sieht das Endergebnis für mich so aus:
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'`];}"
Da Unix-Shell nicht meine native Umgebung ist, werde ich die Optimierungen sehr schätzen.
Nun, und Sie wissen nie, plötzlich wird mich jemand brauchen, ich konnte das nicht googeln.
* Nägel in Communigate Pro wurden wirklich nicht gefunden