Zertifikatsautomatisierung

[Blubmann]

Hallo zusammen,

ich bin neu mit NSP unterwegs und evaluiere gerade das System für uns und unsere Kunden. Ich stoße nun aber seit ein paar Stunden über eine Problem, was ich absolut nicht gelöst bekomme. Wir haben mehrere Kunden, die für Ihre Zertifikate Lets Encrypt benutzen. Ich habe hier auch schon ein paar Einträge zu dem Thema gefunden und entsprechend angefangen das Ganze zu automatisieren. Habe also CertifytheWeb heruntergeladen. Dieses läuft zusammen mit der Gatewayrolle und dem Webportal auf einem Server in der DMZ. Das Zertifikat wird am Webserver aktualisiert, aber an der Gatewayrolle scheitere ich bisher. Im Forum habe ich ein Script gefunden, was die Berechtigungen für die Zertifikate anpasst -> Braucht man das noch? Habe es so getestet, dann heißt es, dass das Zertifikat oder Key nicht gefunden werden kann, wenn ich ihn auswähle. Habe dann festgestellt, dass die Dateien in einem anderen Verzeichnis liegen. Habe das Script angepasst. Anschließend dann der Importbefehl für das Gateway. Nun habe ich den Stand, dass die Intranetrolle meldet, dass das erwarte und das tatsächliche Zertifikat nicht übereinstimmen. Außerdem meldet die Gatewayrolle, das die Überprüfung des privaten Schlüssels unerwartet fehlgeschlagen ist. Der angezeigte Fingerabdruck des Zertifikats kann ich aber nicht zuordnen und in der Ereignisanzeige sehe ich folgenden Fehler:

An unexpected error occurred while processing replication artifacts. Please report this error to the NoSpamProxy support.

Error: The Windows Store does not support adding certificates.


Message:
The Windows Store does not support adding certificates.
Error type:
System.NotSupportedException

Error code: 2148734229
Program location:
bei Netatwork.NoSpamProxy.Cryptography.Certificates.WindowsCertificateStore.Add(Int32 tenantId, IEnumerable`1 certificatesWithKeys, Boolean replicateCertificates)
bei Netatwork.NoSpamProxy.Cryptography.Certificates.GatewayRoleCertificateService.ProcessCertificateArtefacts(ReplicationArtifactAction action, List`1 artifacts)
bei Netatwork.NoSpamProxy.Cryptography.Certificates.GatewayRoleCertificateService.ProcessCertificateArtefacts(ReplicationData`1 data)
bei Netatwork.NoSpamProxy.Replication.ReplicationService.<>c__DisplayClass24_0`1.<SubscribeTo>b__0(ReplicationData`1 items)
bei Netatwork.NoSpamProxy.Replication.ReplicationService.<ExecuteHandlerAsync>d__39.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei Netatwork.NoSpamProxy.Replication.ReplicationService.<DistributeArtifactsAsync>d__38.MoveNext()


Additional data:
Certificate Thumbprints: 1984A710ADE536FC165773C41D8B0D965985BDF1
Store Location: Windows
Store Id: My


Versuche ich das Zertifikat manuell im Command Center auf dem Konnektor zu ändern und starte ihn neu, bleibt der Fehler bestehen. Egal welches Zertifikat eingebunden wird. Ich bin also absolut ratlos, was diese Einbindung angeht. Hat irgendwer Tipps oder eine Anleitung mit der man Lets Encrypt sauber eingebunden bekommt?

 

[Blubmann]

Ok, den oberen Fehler konnte ich beheben indem ich das Gateway aus der Konfig entfernt und neu hinzugefügt habe. Dann wäre jetzt nur noch eine Anleitung wie man Lets Encrypt angebunden bekommt

 

[869288141]

Hallo Blubmann,

Im Forum habe ich ein Script gefunden, was die Berechtigungen für die Zertifikate anpasst -> Braucht man das noch?

Mir ist nichts anderes bekannt. Hast du uns den Link, damit wir alle die gleichen Ausgangsinformationen haben?

Habe es so getestet, dann heißt es, dass das Zertifikat oder Key nicht gefunden werden kann, wenn ich ihn auswähle. Habe dann festgestellt, dass die Dateien in einem anderen Verzeichnis liegen.

Welcher Pfade hat nicht gestimmt?

Nun habe ich den Stand, dass die Intranetrolle meldet, dass das erwarte und das tatsächliche Zertifikat nicht übereinstimmen. Außerdem meldet die Gatewayrolle, das die Überprüfung des privaten Schlüssels unerwartet fehlgeschlagen ist

Kann es sein, dass du zuerst die Gateway Rolle installiert, dann das Zertifikat hinzugefügt hast, die Berechtigungen nicht angepasst hast. Die Berechtigungen im Nachgang korrigiert aber die Gateway Rolle danach nicht neu gestartet?

Dann wäre jetzt nur noch eine Anleitung wie man Lets Encrypt angebunden bekommt

Gibt es meines aktuell kein fertiges Skript. Steht seit zwei Jahren auf meiner ToDo Liste. Gerne teile ich meine Stichpunkte für das Thema:

• Validierung soll/muss bei LE über DNS-01 Challenge erfolgen. Weil NSP kein Webserver mit bringt. Zumal eingehender Traffic ai Destination NAT erfolgt und nur eine öffentliche IPv4-Adresse vorhanden ist. Da zeigt Port 80/443 vermutlich auf einen anderen Hosts.
• Der DNS Hoster muss über eine API verfügen, um temporär einen TXT Eintrag mit dem entsprechende Wert anzulegen.

Die Interaktion muss von dem Server, auf dem die NSP Intranet Rolle installiert ist, ausgehen.

• DNS-Eintrag setzen
• Zertifikat bei LE Anfragen
• Zertifikat speichern
• Zertifikat auf die Gateway Rolle übertragen
• Zertifikat auf der Gateway Rolle installieren
• Berechtigungen des privaten Schlüssel anpassen
• Zertifikat in den Connectoren wechseln
• Gateway Rolle neu starten
• Neuer Fingerprint auf der Intranet Rolle bestätigen
• Falls TLSA Einträge zum Einsatz kommen, muss ein neuer Eintrag für das neue Zertifikat über die API beim DNS Hoster gesetzt werden.
• Validierung /TLSA Check, ob der neue Eintrag korrekt ist.

Ein Webserver, welcher auf dem Server der NSP Intranet Rolle läuft und über Port 80 aus dem Internet erreichbar ist, ist für mich ein Sicherheitsrisiko. Geoblocking auf der Frontend Firewall ist keine Option (mehr). Denn die Validierung ist oder wird in Zukunft nicht mehr nur von einem Server, sondern aus verschiedenen Regionen durchgeführt. Mir fällt gerade ums verdrehen der Begriff nicht ein...

Ist alles kein Act... aber wie immer Theorie vs Praxis und die fehlende Zeit. Aber gerne den Anfang machen.


Gruß,
Daniel

 

[Blubmann]

Tag Daniel,

ich hatte folgendes Script: https://codeberg.org/wd/Powershell-Skripte/src/branch/master/NoSpamProxy/Set-CertificatePermissions

Aber ich glaube die restlichen Probleme sind insofern zu erklären, dass ich das Ganze nicht auf dem Intranetserver versucht habe, sondern auf dem Gateway selbst, was in der DMZ hängt..... Also dahingehend eigentlich erstmal alles ignorieren und vergessen. Wir umschiffen das Thema nun erstmal, dass wir zumindest für die Gatewayrolle ein gekauftes Zertifikat verwenden. Das Webportal ist ebenfalls in der DMZ, da kommt dann CertifytheWeb zum Einsatz.

Aber deine Stichpunkte sind schon mal ganz hilfreich, was zu tun ist. Port 80 auf dem Intranetserver halte ich auch nicht für sinnvoll. Da ist die DNS-Challenge gerade recht, aber durch die Providervielfalt quasi nicht zu generalisieren.
Wir benutzen AutoDNS, da gibt es definitiv eine API und hier gibt es ein Projekt, was in Go geschrieben ist, was auch solche Challenges macht: https://github.com/go-acme/lego/tree/master?tab=readme-ov-file
Evtl. bekommt man dort die API Ansätze in Powershell übertragen. Also falls wir das Produkt in unser Portfolio aufnehmen, dann werde ich schauen, dass ich mal für AutoDNS ein Prototyp baue (klingt nach einer Samstag Abend Nacht und Nebel Powershellprogrammieraktion)., den ich hier teile.


Gruß Fabian

 

[Blubmann]

Bzw. ich sehe gerade, dass es hier schon was für Powershell gibt, zumindest was den Lets Encrypt Ansatz per DNS-Challenge angeht: https://poshac.me/docs/v4/

Gibt einige Plugins für verschiedene Provider

 

[JanJäschke]

Hättest du bereits eine Möglichkeit Dateien einfach zwischen der Intranet Rolle und den Gateways automatisch auszutauschen?

 

[869288141]

ich hatte folgendes Script: https://codeberg.org/wd/Powershell-Skripte/src/branch/master/NoSpamProxy/Set-CertificatePermissions

Hast du mir noch den Beitrag hier Forum, wo der alte Link noch zu finden ist? Dann kann Jan diesen zeitnah ersetzen.

https://poshac.me/docs/v4/

Gibt einige Plugins für verschiedene Provider

Darauf baut meine Idee auf. Einige (Link) ist gut...