Staging-Umgebung

Letzte Änderung: | Gesamte Dokumentation anzeigen

Hinweis: Die englische Version wurde seit der Übersetzung aktualisiert () Auf Englisch anzeigen

Wir empfehlen dringend das Testen gegen unsere Staging-Umgebung, bevor die Produktionsumgebung benutzt wird. Das wird Ihnen erlauben, die Dinge richtig zu machen, bevor vertrauenswürdige Zertifikate ausgestellt werden und reduziert das Risiko, gegen Rate Limits zu laufen.

Die ACME URL für unsere ACME v2 Staging-Umgebung ist:

https://acme-staging-v02.api.letsencrypt.org/directory

Wenn Sie Certbot verwenden, können Sie unsere Staging-Umgebung mit dem --test-cert Flag verwenden. Für andere ACME Clients lesen Sie bitte die Instruktionen für Informationen zum Testen mit unserer Staging-Umgebung. Beachten Sie, die v2 Staging-Umgebung benötigt einen v2 kompatiblen ACME Client.

Rate Limits

Die Staging-Umgebung benutzt dieselben Rate Limits wie beschrieben für unsere Produktionsumgebung mit den folgenden Ausnahmen:

Staging Zertifikatshierarchie

Die Staging-Umgebung hat eine Zertifikatshierarchie, die Produktionsumgebungen emuliert.

Zwischenzertifikate (Intermediate-Zertifikate)

Die Staging-Umgebung verfügt über zwei aktive Zwischenzertifikate: ein RSA-Zwischenzertifikat "(STAGING) Artificial Apricot R3" und ein ECDSA-Zwischenzertifikat "(STAGING) Ersatz Edamame E1".

Die ECDSA-Ausgabe wurde am 24. März 2021 in Staging aktiviert und alle Anforderungen für Staging-Zertifikate mit ECDSA-Schlüsseln werden von “(STAGING) Ersatz Edamame E1” signiert und verwenden die ECDSA-Hierarchie. Ebenso werden alle Anforderungen für Staging-Zertifikate mit RSA-Schlüsseln von „(STAGING) Artificial Apricot R3“ signiert und verwenden die RSA-Hierarchie. Es gibt keine Möglichkeit, ein RSA-signiertes Zertifikat für einen ECDSA-Schlüssel zu erhalten, und auch nicht umgekehrt; um zu bestimmen, welchen Zertifikatsaussteller Sie erhalten, wählen Sie aus, welche Art von Schlüssel Sie lokal generieren.

Wurzelzertifikate (Root-Zertifikate)

Die Staging-Umgebung hat zwei aktive Root-Zertifikate, die in Browser-/Client-Truststores nicht vorhanden sind: “(STAGING) Pretend Pear X1” und “(STAGING) Bogus Broccoli X2”. Wenn Sie einen Test-Client so verändern möchten, dass er der Staging-Umgebung zu Testzwecken vertraut, können Sie dies tun, indem Sie die "(STAGING) Pretend Pear X1" und/oder "(STAGING) Bogus Broccoli X2" Zertifikate zu Ihrem Test-Truststore hinzufügen. Alle unsere Staging-Zertifikate finden Sie hier. Wichtig: Fügen Sie den Staging-Root oder das Zwischenzertifikat nicht zu einem Truststore hinzu, den Sie für das normale Browsen oder für andere Aktivitäten verwenden, da diese nicht geprüft werden oder den gleichen Standards wie unsere Produktionsstammsätze entsprechen als Tests.

Zertifikat Transparenz

Die Staging-Umgebung übermittelt Vorzertifikate an die CT-Testprotokolle von Let’s Encrypt Sapling und Google testtube und schließt zurückgegebene SCTs in die ausgestellten Zertifikate ein.

Kontinuierliche Integration/Entwicklertests

Die Staging-Umgebung hat grosszügige Rate Limits zum Testen, aber passt nicht für Integration in Entwicklungsumgebungen oder Kontinuierliche Integration (CI). Netzwerkanfragen zu externen Servern können Instabilitäten verursachen und die Staging-Umgebung ermöglicht keinen “Fake”-DNS oder Challenge Validation, was das Testen komplizierter macht.

Zusätzlich zur Staging-Umgebung bietet Let’s Encrypt einen kleinen ACME Server zum Einbau in CI und Entwicklungsumgebungen namens Pebble an. Es ist schnell und einfach, Pebble in Ihrer Entwicklungsmaschine oder in einer CI Umgebung zu starten.