Lets Encrypt Zertifikate

[righter]

Hallo folgendes Setup

2x Gateway Server
1x Intranet Server

Wie ich das ganze Zert einspielen kann ist mir klar, nur die Funktion des Set-NspReceiveConnector ist mir nicht ganz klar:
Muss ich das Zert nur auf dem Intranet Server in den Windows Store importieren und der Set-NSP deployed es dann auf die 2 Gateway Server?
Muss man noch spezielle Berechtigungen auf dem Zert setzen nach dem Windows Import?

Danke

 

[JanJäschke]

Guten Morgen =)

du musst die Zertifikate auf den Gateways und falls vorhanden auf den Web Portalen inklusive privatem Schlüssel bereitstellen.
Derzeit werden die TLS Zertifikate nicht entsprechend von der Intranet Rolle repliziert da wir hier noch sehr stark auf die Windows Komponenten zurückgreifen.
Rechte für das Gateways Rollen Zertifikat müssen gesetzt werden, hier einmal ein kleiner Überblick zum generellen Vorgehen beim TLS Wechsel:

Austauschen der TLS-Zertifikate

docs.nospamproxy.com

Beim Web Portal ist noch zu beachten, dass das neue Zertifikat akzeptiert werden muss, dafür musst du per Get-NspIssues die Issues abfragen und dann das entsprechende Issue mit Invoke-NspIssueAction akzeptieren. (Pipen)


Beste Grüße,
Jan

 

[righter]

Hallo

Also der Prozess wäre wie folgt:
- GW Server 1: Zertifikat importieren
- GW Server 1: LOCAL Service und NETWORK Service Read Permission auf den Private Key geben
- GW Server 1: Zertifikat dem IIS zuweisen
- GW Server 2: Zertifikat importieren
- GW Server 2: LOCAL Service und NETWORK Service Read Permission auf den Private Key geben
- GW Server 2: Zertifikat dem IIS zuweisen
- Intranet Server: Web Portal Zertifikat vom GW Server 1 akzeptieren
- Intranet Server: Web Portal Zertifikat vom GW Server 2 akzeptieren
- Intranet Server: Zertifikat dem Receive connectors zuweisen
- GW Server 1: Gateway Rolle neu starten
- GW Server 2: Gateway Rolle neu starten

Wir haben über 200 unterschiedliche Sachen mit Lets Encrypt automatisiert. Wie soll man den obigen Ablauf scripten?

 

[869288141]

Moin,

Wie soll man den obigen Ablauf scripten?

Kann man per PowerShell machen. Ist zwar recht umfangreich, wenn man Fehlerfälle abfängt, aber ist machbar.


Gruß,
Daniel

 

[righter]

@869288141 Hast du ein Beispiel Script wo das schon realisiert wurde?

 

[869288141]

Ja, das darf ich aber nicht herausgeben. Ich wollte es mal selber schreiben, aber aus Mangel an Zeit noch offen.

 

[JanJäschke]

Ich kann ggf. die Tage was teilen, dann musst du dich nur um die Übertragung der Zertifikate kümmern.
Damit wäre also Import, Rechte und Issue abgedeckt - musst nur die PFXs Dateien haben

Eine native Lösung wäre mir auch lieber, aber der Aufwand ist derzeit zu hoch um das "mal eben zwischen zu schieben" ^^

 

[righter]

@JanJäschke
Wenn man sich Verkürzung der Laufzeit anguckt, wäre es gut wenn ihr da bald mal eine sauber ACME Implementierung plant.
Oder sonst ein offizielles Script, mit welchem man das ganze sauber implementieren kann.

Beschlossen: Lebensdauer für TLS-Serverzertifikate sinkt auf 47 Tage

Von derzeit maximal dreizehn Monaten sinkt die Gültigkeit auf anderthalb. Allerdings mit jahrelanger Übergangsfrist für Admins.

www.heise.de

Heutzutage ist das ja eigenltich Standard

 

[JanJäschke]

Ich arbeite dran
Mit dem neuen WebPortal werdet ihr auf jeden Fall problemlos einen ACME Client verwenden können.
Bleibt dann nur noch das GW und eine native ACME Implementierung auf unserer Seite.

ACME an sich ist nicht kompliziert, dass aber mit uns und der teils alten Struktur direkt zu verheiraten schon eine größere Hürde ^^

Aber es wird

 

[righter]

Jo Web Portal kann notfalls auch mit Proxy simpel gelöst werden.
Unsere beiden Gateways sehe ich da problematischer.

Ihr habt ja noch Zeit dies zu implementieren.

Gut, dass ihr da dran seid.

 

[869288141]

Ihr habt ja noch Zeit dies zu implementieren.

Naja, das ist nur die halbe Miete. In Regelfall hast du noch die passenden TLSA Einträge... da wird es keine Lösung geben.

Unsere beiden Gateways sehe ich da problematischer.

In wie fern? Bei meinem vorherigen AG haben wir LE schon vor 4 Jahren für NSP eingesetzt. Es ist alles da, was man dafür seitens NSP braucht. Nur erwartet jeder 0815 IT Administrator, eine schlüsselfertige Lösung und das zum Nulltarif...

Bleibt dann nur noch das GW und eine native ACME Implementierung auf unserer Seite.

Ich kenn die Pläne bisher nicht. Aber bitte auf jeden Fall sowohl HTTP-01 als auch DNS-01 Challenge implementieren.

 

[JanJäschke]

Ich kenn die Pläne bisher nicht. Aber bitte auf jeden Fall sowohl HTTP-01 als auch DNS-01 Challenge implementieren.

Plan ist derzeit nur DNS-01 zu machen. Dadurch können wir zentral verwaltet in der Intranet Rolle erledigen und der Admin müsste wirklich nichts mehr machen.
Prinzip sieht so aus, dass man als Administrator einmalig einen C-Name setzt für die Validierung. Die entsprechenden DNS Token würden dann an "service.nospamproxy.com" übermittelt werden und zur Validierung führen.
Das ermöglicht jedem DNS-01 komplett automatisch zu benutzen ohne, dass wir X Provider-Schnittstellen unterstützen müssten, verwaltet es Zentral für alle GWs und WPs, was Logging, error Handling, Analyse sowie Kommunikation deutlich vereinfacht

Siehst du bei HTTP-01 einen Vorteil im Vergleich zu meiner Beschreibung?

 

[righter]

In wie fern? Bei meinem vorherigen AG haben wir LE schon vor 4 Jahren für NSP eingesetzt. Es ist alles da, was man dafür seitens NSP braucht. Nur erwartet jeder 0815 IT Administrator, eine schlüsselfertige Lösung und das zum Nulltarif...

Ja wenn ich ein Produkt kaufe erwarte ich ein einfaches Handling für die Zertifikate
Eine API würde mir schon reichen um das sauber zu implementieren. Das wäre meine favorisierte Lösung
So ein Powershell Gewürge für NSP zu bauen ist machbar ja, aber weit weg von einer sauberen Implementation.

 

[869288141]

Plan ist derzeit nur DNS-01 zu machen. Dadurch können wir zentral verwaltet in der Intranet Rolle erledigen und der Admin müsste wirklich nichts mehr machen.

Sehr gut. D.h. die Realisierung basiert auf ACME, um eine möglichst große Anzahl von Providern zu unterstützen?

Prinzip sieht so aus, dass man als Administrator einmalig einen C-Name setzt für die Validierung. Die entsprechenden DNS Token würden dann an "service.nospamproxy.com" übermittelt werden und zur Validierung führen.

Der Lösungsansatz gefällt mir nicht. Das ist eine Abhängigkeit im DNS zu euch, die wir nicht unter Kontrolle haben. Da wünsche ich mir vollständige Unabhängigkeit. Da werden euch die Behörden (Bund, Land, Kommune) auf die Füße stehen.

Siehst du bei HTTP-01 einen Vorteil im Vergleich zu meiner Beschreibung?

Aktuell nicht. Zumal meine Setups nicht eines 0815 Kunden entsprechen. Lass mich drüber nachdenken....

 

[869288141]

Eine API würde mir schon reichen um das sauber zu implementieren. Das wäre meine favorisierte Lösung

Bin ich bei dir. Gerade auf Hinblick für die Instanzen welche nicht dem 0815 Muster entsprechen. Sprich sobald Loadbalancer, WAF, CDNs, etc. zum Einsatz kommen. Zudem soll es Admins geben, die sogar TLSA Einträge im DNS erstellen/aktualisieren. Somit kann jeder Verantwortliche wählen zwischen UI oder API.

Ja wenn ich ein Produkt kaufe erwarte ich ein einfaches Handling für die Zertifikate

Was soll ich sagen... meine Erwartungsliste wird auch nicht kürzer. Vermutlich setzt NSP bei meinen E-Mails inzwischen einen roten Banner.

So ein Powershell Gewürge für NSP zu bauen ist machbar ja, aber weit weg von einer sauberen Implementation.

Das lässt sich durch aus sauber planen, entwickeln und produktiv einsetzen. Klar es kostet Zeit, Nerven und Zucker.