Infoanlass: Austausch der SSL/TLS Zertifikate

Transkript

1 Infoanlass: Austausch der SSL/TLS Zertifikate

2 Agenda Begrüssung Informationen zum Austausch der SSL/TLS-Zertifikate der SSL CA01: Ausgangslage Folgen Neue SG-Root CA III Verfügbarkeit und Einschränkungen der Root CA III Prozess Berechtigungen/ Bestellung und Download Vorgehen beim Austausch der SSL CA 01 Zertifikate Alternativen Verrechnung Schulung/ Präsentation CRW Fragen 2

3 Timeline Anfangs 2016: Aufgrund neuer Anforderungen ist die Root II nicht mehr für SSL/TLS Zertifikate zertifizierbar Erstellung SG-Root CA III am 15. April 2016 Zertifizierung der Root CA III nach Auditierung Ende 2016: 25. Januar 2017 Anmeldung zur Aufnahme in den Truststores ab Januar 2017 (Microsoft/ Mozilla/ Apple) Wartezeit von 6 Monaten für die Aufnahme Juli 2017 Aufgrund der Verzögerungen zur Aufnahme in den Truststores von Mozilla und Apple wurde im Juni die Entscheidung gefällt, die neue ausstellende CA durch eine externe Root signieren zu lassen um die Unterstützung in allen Browsern sicherzustellen. 3

4 Ausgangslage Ablauf des Cross-Signed Zertifikates für die SG-SSL CA01 Das «Baltimore» Cross-Signed Zertifikat für die SSL CA01 läuft am um 20:50 Uhr ab! Welche Zertifikate sind davon betroffen?: Alle SSL/TLS Zertifikate, die von der Swiss Government SSL CA01 ausgestellt wurden und deren Validierungspfad über die «Baltimore Root» läuft. 4

5 Ausgangslage 2 Information aus der letzten Newsletter (Feb. 2017): Die immer strengeren Normen und Anforderungen, die von Seiten der Internet Community und insbesondere des CA-Browserforums an eine ausstellende CA gestellt werden, erzwingen für eine internationale Anerkennung die ständige Evolution und Innovation der Richtlinien (insb. der CP/CPS) und die Aufrüstung und Anpassung der Systeme. Wie bereits seit einigen Jahren mitverfolgt werden kann, sind in Bezug auf SSL Zertifikatausstellende Autoritäten (CAs) die meisten Änderungen an Normen und Standards erfolgt. In den letzten Jahren haben uns diese Änderungen mehrmals dazu veranlasst, neue ausstellende CAs aufzustellen (Die Sub-Roots der Root CA II, sprich z.b. die Swiss Government SSL CA 01 und Swiss Government EV SSL CA01). Aktuelle Veränderungen in den Standards führten nun dazu, dass eine weitere Root CA aufgebaut werden musste: Die Swiss Government Root CA III wurde nun neu für die zukünftigen «publicly trusted Certificates» am 15. April 2016 ins Leben gerufen und wird ab dem Zeitpunkt Ihrer Zertifizierung für alle «public trusted Certificates» eingesetzt werden. Dies bedingt, dass die Root III und Ihre Ausstellenden CAs in den gängigen Browsern inkl. den Mozilla/Firefox-Store integriert werden müssen. Verläuft die Auditierung und die Aufnahme in den Browsern nach Plan, werden die CAs der Root III spätestens ab Juli 2017 bereit sein und SSL, EV SSL und (EV) Code Signing Zertifikate ausstellen können. 5

6 Folgen Folgen: Keine Validierung über die «Baltimore Root» möglich Die Zertifikate werden ab dem , unabhängig vom eigenen Ablaufdatum von allen Browsern als «ungültig» erklärt. Konsequenz der SG-PKI für die Root II und die SSL CA01 Die SG Root CAII und die SSL CA01 sind für SSL/TLS nicht mehr zertifizierbar Die SSL CA01 muss per Ende 2017 dekommissioniert werden (= abgestellt!) Die CRL wird weiterhin bis zur Gültigkeit des letzten Zertifikates publiziert. Eine SG Root CA III mit allen aktuellen, internationalen Anforderungen des Browser Forums wurde am 15. April 2016 erstellt und per 25. Januar 2017 erfolgreich zertifiziert 6

7 Swiss Government Root CA III 7

8 Stand Swiss Government Root CA III Die Swiss Government Root CA III ist seit dem 25. Januar 2017 von KPMG auditiert und zertifiziert Die Swiss Government Root CA III ist seit April 2017 im Trusted-Root Store von Microsoft implementiert Die SG PTST CA02 wird durch einen, bereits in allen Browsern eingetragenen Zertifikats-Anbieter, root-signiert Mögliche Anbieter wurden kontaktiert Verfügbar voraussichtlich Mitte Juli 2017 Die Verhandlungen um direkt in alle Browser-Truststores aufgenommen zu werden laufen weiterhin 8

9 Verfügbarkeit der neuen ausstellenden CA für SSL/TLS Neue ausstellende Sub-CA für SSL/TLS Zertifikate unter der SG Root CA III ist die Swiss Government Public Trust Standard CA 02 (Abk. SG PTST CA02) Die neue SG PTST CA02 ist ab sofort verfügbar! 9

10 Verfügbarkeits-Einschränkungen Für die SG PTST CA02 muss die Berechtigung mittels Antragsformular neu beantragt werden Für jede Domäne muss der Domain-Owner den Antrag unterschreiben (z.b. für «admin.ch» = Staudenmann René BIT) Die SG PTST CA02 ist publicly trusted (aktuell nur bei Microsoft eingetragen!) Kurz-Schulung des Ausstell- Tools (CRW) nötig 10

11 Ausstellung der neuen SSL/TLS Zertifikate Die Ausstellung der neuen SSL Zertifikate erfolgt nicht mehr über das WebInterface Neu wird das CRW* benutzt, welches bereits für die Standard Klasse C Zertifikate in Gebrauch ist *Certificate Request Wizard 11

12 Prozess für die Ausstellung neuer SSL/TLS auf der SG PTST CA02 1) Berechtigungsanfrage mittels Formular 1 für alle Domains in eigenen Verantwortungsbereich 2) Freigabe des CRW auf dem eigenen Client (Auf BAB-Clients im den «Swiss Government PKI»- Paket enthalten 3) SSL-Infoanlass (heute, ), oder Schulung für Klasse C Zertifikate besucht 4) Der Request wird im CRW eingegeben und zur Validierung an das OM der SG-PKI versendet 1 Neue Formulare für die SSL/TLS Ausstellung werden ab ca. Anfang Juli auf der PKI-Homepage zur Verfügung stehen Info an alle bereits Berechtigte folgt per e- Mail! 12

13 Download 5) Die Validierung des Requests wird innerhalb von 2 Arbeitstagen bearbeitet. 6) Nach der Validierung kann das Zertifikat vom berechtigten Benutzer im CRW abgeholt werden. Installation: Bitte achten Sie bei der Bestellung auf die Wahl der korrekten Policy (Validierungspfad über Root CA III oder Browser-compatible) 13

14 Vorgehen beim Austausch der SSL- Zertifikate Entscheidung: Ist das Zertifikat im Internet «sichtbar»? 1. Check: Liste online verfügbar! (Liste nicht abschliessend!!!) 2. Check: Was nicht auf der Liste: Check ob der «Service» nicht doch im Internet steht. Steht der Service im Internet, braucht es ein Zertifikat vom Typ: «SSL/TLS Browser-Compatible» Steht der Service NICHT im Internet können Sie eine ALTERNATIVE wählen! 14

15 Alternativen zu den SSL/TLS Zertifikaten der SG SSL CA01 Alternative 1: Systeme welche ausschliesslich Microsoft Windows Truststore einsetzen können ab sofort die neuen Zertifikate der SG PTST CA 02 verwenden Service/ Server im Internet sichtbar und es wird nur von Windows (Microsoft)- Systeme verwendet Neues Zertifikat von der neuen SG PTST CA02 ausstellen und installieren, Validierungspfad updaten! 15

16 Alternativen zu den aktuellen SSL/TLS Zertifikaten der SG SSL CA01 Alternative 2: Systeme innerhalb der BVerw sollten Zertifikate der Klasse E einsetzen. Diese sind im BV-Netz trusted, verfügbar und in einem «automatischen Prozess» ausstellbar. Service/ Server innerhalb des BV- Netzes keine Präsenz im Internet Informationen und Anleitungen auf der Seite: 16

17 Alternativen zu den aktuellen SSL/TLS Zertifikaten der SG SSL CA01 Alternative 3: Ebenfalls stehen für «Systeme» auch Klasse C Standard Zertifikate zur Verfügung. Die Systemzertifikate mit den Funktionen System/Client- Sign Encrypt Authentication Explizit keine Server-Auth Funktion! (oder in einer Kombination der Funktionen) können mit den nötigen Berechtigungen und der Schulung des CRW-Tools gleichfalls von der SG-PKI bezogen werden. Informationen/ Ausprägungen und Anleitungen auf der Seite: 17

18 Zusammenfassung Es gibt über 8500 Zertifikate die auf der SSL CA 01 ausgestellt sind Ca davon sind tatsächlich im Internet sichtbar Prüfung, ob es tatsächlich ein SSL/TLS (Server Auth) sein muss ist vorgängig notwendig Wenn nicht: Alternativen prüfen: Welcher Typ Zertifikat könnte zum Zug kommen? Anleitungen auf der Homepage unter dem gewünschten Typ lesen Ggf. Berechtigungen anfordern und ggf. Kurz-Schulung besuchen (wenn nicht am Infoanlass vom präsent) Zertifikat der SSL CA01 austauschen Den korrekten Validierungspfad eintragen 18

19 Und wenn das Zertifikat publicly trusted sein MUSS? Beginnen Sie die Zertifikate in Ihrem Verantwortungsbereich zu klassifizieren (publicly trusted vs. not relevant) Entscheiden Sie mit welchem Typ Sie diese Zertifikate ersetzen wollen Beantragen Sie die nötigen Berechtigungen Ersetzen Sie zuerst alle anderen Zertifikate gewinnen Sie Zeit! Warten Sie auf die Info der SG-PKI, dass die «Browser Compatible» Variante verfügbar ist (ca. Mitte Juli 2017) Ersetzen Sie nun ab August 2017 die publicly trusted Zertifikate mit den neuen SSL/TLS Zertifikaten der SG PTST CA02 und aktualisieren Sie die Zertifizierungspfad um die korrekte Validierung in allen Browsern zu gewährleisten. 19

20 Verrechnung Bis anhin: Es bestand auf der SSL CA 01 keine Möglichkeit Rückschlüsse auf die ausstellende Person zu ziehen! Die Verrechnungsgrundlagen wurden manuell erstellt, je nach FQDN das im Zertifikat angegeben wurde, konnte das Amt ausfindig gemacht werden oder nicht: Hohe Fehlerquote / Korrekturen im MLR notwendig nur ca. 1/3 der Zertifikate konnte verrechnet werden Wir bitten für alle Unannehmlichkeiten die damit in Verbindung standen um Entschuldigung! 20

21 Verrechnung Bis anhin: Es bestand auf der SSL CA 01 keine Möglichkeit Rückschlüsse auf die ausstellende Person zu ziehen! Die Verrechnungsgrundlagen wurden manuell erstellt, je nach FQDN das im Zertifikat angegeben wurde, konnte das Amt ausfindig gemacht werden oder nicht: Hohe Fehlerquote / Korrekturen im MLR notwendig nur ca. 1/3 der Zertifikate konnte verrechnet werden Wir bitten für alle Unannehmlichkeiten die damit in Verbindung standen um Entschuldigung! 21

22 Verrechnung Neu (Ausstellung über das CRW): Die ausstellende Person ist der Besteller Die Verrechnungsgrundlagen werden automatisch dem MLR eingetragen Der FQDN ist für die Verrechnung nicht mehr relevant Zukünftig werden nur noch Zertifikate der neuen Ausstellumgebung verrechnet. Die Zertifikate der alten SSL CA 01 werden NICHT mehr verrechnet! Fehlerquote/ Korrekturen niedrig, der Aussteller ist für die SG-PKI der Kostenverursacher. (Die SG-PKI wird KEINE Weiterverrechnung veranlassen, die SSL-LRAOs sind sich der Kosten bewusst und lösen die Weiterverrechnung ggf. selber aus) Alle Zertifikate können korrekt verrechnet werden Der Report ist jederzeit im MLR ersichtlich 22

23 Entschuldigung Wir bitten für alle Unannehmlichkeiten die dadurch entstehen um Entschuldigung! 23

24 CRW (Certificate Request Wizard) Salvatore Tomasulo ( Siehe separate Quick-Guide) 24

25 Ist das «Chaos» nun «perfekt»? 25

26 Danke! 26