SSL-Zertifikatverwaltung: Vom Chaos auf Hunderten von Servern bis zur zentralen Lösung

Was kann hinter den Worten „Europas größte Online-Schule“ stehen? Einerseits sind dies 1000 Lektionen pro Stunde, 10 000 Lehrer, 100 000 Schüler. Und für mich, einen Infrastrukturingenieur, umfasst dies auch mehr als 200 Server, Hunderte von Diensten (mikro und nicht sehr) sowie Domainnamen von der 2. bis zur 6. Ebene. Überall benötigen Sie SSL und dementsprechend ein Zertifikat dafür.



Zum größten Teil verwenden wir Let's Encrypt-Zertifikate. Ihre Vorteile sind, dass sie kostenlos sind und die Quittung vollautomatisch ist. Auf der anderen Seite haben sie eine Eigenschaft: kurze - nur drei Monate - Gültigkeit. Dementsprechend müssen sie regelmäßig aktualisiert werden. Wir haben versucht, es irgendwie zu automatisieren, aber es gab immer noch viel manuelle Arbeit und etwas brach ständig. Vor einem Jahr haben wir eine einfache und zuverlässige Methode zur Aktualisierung dieses Zertifikatsstapels entwickelt und seitdem dieses Problem vergessen.

Von einem Zertifikat auf einem Server bis zu Hunderten in mehreren Rechenzentren


Es war einmal nur ein Server. Und darauf lebte ein Certbot, der unter der Krone hervorkam. Dann hat ein Server die Last nicht mehr bewältigt, sodass ein anderer Server angezeigt wurde. Und dann immer mehr. Jeder von ihnen hatte seine eigenen Zertifikate mit seinen eigenen eindeutigen Namen, und überall war es notwendig, ihre Aktualisierung zu konfigurieren. Irgendwann während der Erweiterung haben sie vorhandene Zertifikate kopiert, aber das Update vergessen.

Um ein Let's Encrypt-Zertifikat zu erhalten, müssen Sie den Besitz des im Zertifikat angegebenen Domänennamens bestätigen. Dies erfolgt normalerweise mit einer umgekehrten HTTP-Anforderung.


Hier sind einige Standardschwierigkeiten, auf die wir während unseres Wachstums gestoßen sind:

  • : . .
  • HTTP. , . . - LDAP. - . .

An einigen Stellen werden seit geraumer Zeit selbstsignierte Zertifikate verwendet, und dies schien eine gute Lösung zu sein, wenn keine Authentifizierung erforderlich ist - beispielsweise für interne Tests. Um zu verhindern, dass der Browser ständig eine „verdächtige Site“ meldet, müssen Sie nur unser Stammzertifikat zur Liste der vertrauenswürdigen hinzufügen, und der Punkt liegt im Hut. Aber auch hier traten spätere Schwierigkeiten auf.



Das Problem ist, dass es in BrowserStack, den Tester verwenden, unmöglich ist, ein Zertifikat zur vertrauenswürdigen Liste für mindestens iPad, Mac, iPhone hinzuzufügen. Daher mussten sich Tester ständig Popup-Warnungen vor gefährlichen Websites gefallen lassen.

Suche nach einer Lösung


Zunächst müssen Sie natürlich eine Überwachung durchführen, um Informationen zu Zertifikaten zu erhalten, die nicht enden, wenn sie bereits beendet wurden, sondern etwas früher. Gut. Die Überwachung ist, wir wissen jetzt, dass Zertifikate hier und da bald enden werden. Und was kann ich jetzt tun?


Big Ear ist ein alter Bot, der ein Zertifikat nicht ruiniert.

Und verwenden wir Platzhalterzertifikate? Lasst uns! Let's Encrypt gibt sie bereits aus. Richtig, Sie müssen die Bestätigung des Domänenbesitzes über DNS konfigurieren. Und unser DNS lebt in AWS Route53. Außerdem müssen Sie die Zugriffsdetails in AWS auf allen Servern aufteilen. Und mit dem Aufkommen neuer Server kopieren Sie all diese Wirtschaftlichkeit auch dort.

Nun, Namen der 3. Ebene werden durch Platzhalter abgedeckt. Und was tun mit Namen der 4. Stufe und höher? Wir haben viele Teams, die sich mit der Entwicklung verschiedener Dienstleistungen befassen. Jetzt ist es üblich, das Frontend und das Backend zu teilen. Und wenn das Frontend einen Namen der dritten Ebene wie service.skyeng.ru erhält , versucht das Backend, den Namen api.service.skyeng.ru zu vergeben . Hmm, vielleicht verbieten sie ihnen, das weiter zu machen? Eine super Idee! Und was tun mit Dutzenden von existierenden? Könnte es mit eiserner Hand sein, sie alle in einen Domainnamen zu treiben? Ersetzen Sie alle diese Namen verschiedener Ebenen durch URLs wie skyeng.ru/service. Technisch gesehen ist dies eine Option, aber wie lange dauert es? Und wie kann das Geschäft die Notwendigkeit solcher Maßnahmen rechtfertigen? Wir haben mehr als 30 Entwicklungsteams, überzeugen Sie alle - es wird mindestens sechs Monate dauern. Und wir schaffen einen einzigen Fehlerpunkt. Ob es Ihnen gefällt oder nicht, dies ist eine kontroverse Entscheidung.

Welche anderen Ideen gibt es? .. Vielleicht kann ein Zertifikat erstellt werden, in dem wir alles zusammenfassen? Und wir werden es auf allen Servern installieren. Dies könnte die Lösung für unsere Probleme sein, aber mit Let's Encrypt können Sie nur 100 Namen im Zertifikat haben, und wir haben bereits mehr als einen Microservice.

Was tun mit Testern? Sie haben sich nichts ausgedacht, aber sie beschweren sich ständig. Alles Blödsinn außer den Bienen. Bienen sind auch Müll, aber es gibt viele von ihnen. Jeder Entwickler oder Tester erhält einen Testserver - wir nennen ihn Testen. Tests sind keine Bienen, aber es gibt bereits über hundert davon. Und für jedes werden alle Projekte bereitgestellt. Das ist alles. Und wenn Sie zum Verkauf N Zertifikate benötigen, gibt es für jeden Test den gleichen Betrag. Bisher sind sie selbst signiert. Es wäre toll, sie durch echte zu ersetzen ...

Zwei Spielbücher und eine Quelle der Wahrheit


Der Schwan, der Krebs und der Hecht bringen den Wagen nirgendwo hin. Wir brauchen einen einzigen Server Kontrollcenter . In unserem Fall ist dies Ansible. Certbot auf jedem Server ist böse. Lassen Sie alle Zertifikate an einem Ort aufbewahren. Wenn irgendwo jemand ein Zertifikat benötigt, kommen Sie an diesen Ort und nehmen Sie die neueste Version aus dem Regal. Und wir werden sicherstellen, dass die Zertifikate in diesem Geschäft immer auf dem neuesten Stand sind.

AWS-Zugriffsdetails sind auch nur an einer Stelle vorhanden. Dementsprechend verschwinden Fragen wie das Einrichten der AWS-CLI auf einem neuen Server, der Zugriff auf Route53 und dergleichen hat.

Alle erforderlichen Zertifikate werden in einer Datei in Ansible im YAML-Format beschrieben:

    certificates:
      - common_name: skyeng.ru
        alt_names:
          - *.skyeng.ru
      - common_name: olympiad.skyeng.ru
        alt_names:
          - *.olympiad.skyeng.ru
          - api.content.olympiad.skyeng.ru
          - games.skyeng.ru
      - common_name: skyeng.tech
        alt_names:
          - *.skyeng.tech

      .  .  .

In regelmäßigen Abständen wird ein Playbook veröffentlicht, das diese Liste durchläuft und seine harte Arbeit leistet - im Wesentlichen dasselbe wie certbot:

  • Erstellt ein Konto bei Let's Encrypt Certificate Authority
  • generiert einen privaten Schlüssel
  • generiert ein (noch nicht signiertes) Zertifikat - die sogenannte Zertifikatsignierungsanforderung
  • sendet eine Signaturanfrage
  • erhält eine DNS-Abfrage
  • Setzt empfangene Einträge in DNS
  • sendet erneut eine Signaturanforderung
  • und nachdem er das signierte Zertifikat erhalten hat, legt er es in den Laden.

Das Playbook wird einmal am Tag aufgeführt. Wenn er aus irgendeinem Grund keine Zertifikate erneuern konnte - sei es Netzwerkprobleme oder einige Fehler auf der Seite von Let's Encrypt - ist dies kein Problem. Wird beim nächsten Mal aktualisiert.

Wenn jetzt SSL auf einem Service-Host benötigt wird, können Sie in dieses Repository gehen und einige Dateien von dort abrufen - der einfachste Vorgang, den das zweite Playbook ausführt ... Welche Zertifikate auf diesem Host benötigt werden, wird in den Parametern dieses Hosts in inventories / host_vars / server beschrieben .yml :

    certificates:
      - common_name: skyeng.ru
        handler: reload nginx
      - common_name: crm.skyeng.ru

      .  .  .

Wenn sich die Dateien geändert haben, zieht Ansible einen Haken - es ist typisch, Nginx neu zu starten (in unserem Fall ist dies die Standardaktion). Auf die gleiche Weise können Sie Zertifikate von anderen Zertifizierungsstellen erhalten, die das ACME-Protokoll verwenden.

Gesamt


  • Wir hatten viele verschiedene Konfigurationen. Es brach ständig etwas zusammen. Oft musste ich auf Server klettern und herausfinden, was wieder heruntergefallen war.
  • Jetzt haben wir zwei Spielbücher und alles wird an einem Ort aufgezeichnet. Alles funktioniert wie eine Uhr. Das Leben ist langweiliger geworden.

Testen


Ja, was ist mit Testern mit ihren Tests? Jeder Entwickler oder Tester erhält einen persönlichen Testserver - Test. Derzeit gibt es etwa 200 von ihnen. Sie haben Namen der Form test-y123.skyeng.link , wobei 123 die Testnummer ist. Das Erstellen und Entfernen von Tests erfolgt automatisiert. Eine der Komponenten der Aktion ist die Installation eines SSL-Zertifikats. Im Voraus wird ein SSL-Zertifikat mit Namen nach Vorlage generiert:

    ssl_cert_pattern:
      - *
      - *.auth
      - *.bill

      .  .  .

Nur etwa 30 Namen. Das Zertifikat enthält also Namen

    test-y123.skyeng.link
    *.test-y123.skyeng.link
    *.auth.test-y123.skyeng.link
    *.bill.test-y123.skyeng.link

usw.

Nach der Entlassung des Entwicklers oder Testers wird sein Test gelöscht. Das Zertifikat bleibt einsatzbereit. Es ist alles gespeichert. Sie selbst wissen, wo es in Hosts zerlegt wird, Sie selbst wissen, wie.

PS


Repository mit Code .

Es könnte auch interessant sein, zu diesem Thema zu lesen, wie der Stapelüberlauf auf HTTPS umgestellt wurde :

  • Hunderte von Domänen auf verschiedenen Ebenen
  • Websockets
  • Viele HTTP-APIs (Proxy-Probleme)
  • Tun Sie alles und verlieren Sie nicht die Leistung

Wenn Sie Fragen haben, schreiben Sie in die Kommentare, ich werde gerne antworten.

All Articles