Der Dienstleister Sectigo hat den Vertrag zwischen ihm und GÉANT gekündigt, auf dessen Basis der Trusted Certificate Service (TCS) im Rahmen der DFN-PKI erbracht wird.

Zwischen Sectigo und GÉANT gibt es Uneinigkeit über zentrale Vertragsfragen. Dies betrifft u.a. den Zeitpunkt, zu dem die Kündigung wirksam werden soll, und die Leistungserbringung an einzelne versorgte Einrichtungen.

Derzeit gehen wir davon aus, dass Sectigo die Leistungserbringung zum 10.01.2025 einstellen wird.

Wir arbeiten intensiv mit GÉANT zusammen, um ein lückenloses Weiterbestehen der TCS-Dienstleistung mit einem neuen Anbieter zu ermöglichen. Selbstverständlich erkunden wir auch die Möglichkeiten für ein eigenes unabhängiges Angebot.

Zum aktuellen Zeitpunkt können wir leider keine konkreteren Angaben machen.

Der aktuelle Stand ist, dass Sectigo den Vertrag schriftlich gekündigt hat und die Verhandlungen über eine Verlängerung gescheitert sind. Wir gehen derzeit davon aus, dass dies keine Option ist, da Sectigo keine Bereitschaft zeigt, die aktuellen Bedingungen mit sinnvollen oder nachvollziehbaren Anpassungen fortzuführen.

Die aktuelle Vertragsperiode von GÉANT mit Sectigo endet Ende April 2025. Sectigo interpretiert die Vertragslage derart, dass sie bereits zum 10.01.2025 die Leistungserbringung beenden können. Wir müssen davon ausgehen, dass Sectigo spätestens zu diesem Zeitpunkt die Ausstellung von Zertifikaten einstellt.

Wir wissen derzeit nicht, ob nach dem 10.01. noch ein Login in das SCM zur Verwaltung der bestehenden Zertifikate möglich ist.

Wir halten dies für äußerst unwahrscheinlich. Nach Aussage von GÉANT gibt es klare vertragliche Regelungen, dass nicht gesperrt werden darf.

Jenseits der vertraglichen Gründe ist eine Sperrung von Zertifikaten aus kommerziellen Gründen (z.B. zum Vertragsende) nach unserer Einschätzung nicht im Interesse von den Root-Programmen der Browser und Betriebssystemhersteller.

Bei einigen Einrichtungen blockiert Sectigo derzeit die Zertifikatvergabe und fordert Nachweise zur Nutzungsberechtigung gemäß des Vertrags zwischen GÉANT und Sectigo. Dies äußert sich beispielsweise durch eine Fehlermeldung bei der Zertifkatausstellung: Certificate has been rejected: Pre Validation ID 123456789 is not available.

Betroffen sind Einrichtungen, von denen Sectigo nach uns nicht bekannten Parametern behauptet, dass sie weder Teil des jeweiligen Forschungsnetzes wären, noch dass sie in den Bereich „Forschung“ passten.

Selbstverständlich waren und sind alle am DFN teilnehmenden Einrichtungen, auch nach Einschätzung GÉANTs, berechtigt, den Dienst zu nutzen. Trotzdem gehen wir aktuell nicht davon aus, dass wir seitens DFN oder GÉANT etwas unternehmen können, um diese Einrichtungen zumindest bis zum 10.01. wieder freizuschalten.

Die Blockade durch Sectigo ist im Cert-Manager auch für uns nicht sichtbar. Falls Sie hiervon betroffen sind, wenden Sie sich bitte direkt an die DFN-PCA (dfnpca@dfn-cert.de).

Der Vertragspartner von Sectigo ist GÉANT. GÉANT prüft, welche Schritte sinnvoll und rechtlich möglich sind. Dies wird aber vor allem aus Zeitgründen keine Lösung für die Nichterbringung der Leistung nach dem 10.01. bringen, da eine mögliche entsprechende Rechtsklärung wohl zu spät erfolgen würde.

Dokumentensignatur ist ein sehr wichtiges Thema, dass weiterhin von uns große Beachtung findet. CodeSigning hat in der derzeitigen TCS-PKI nur eine sehr geringe Nutzung (64 gültige Zertifikate in 2024-11).

Beide Themen stehen bei einer kurzfristigen Übertragung an einen anderen Dienstleister zunächst nicht im Fokus, da die verbleibende Zeit nicht für notwendige detailliertere Betrachtungen dieser Themen ausreicht.

Eine Wiederbelebung der DFN-PKI Global ist nicht möglich. In den wenigen Monaten seit Aussetzen der DFN-PKI Global haben sich die Anforderungen an den Betrieb in einem derart rasanten Tempo weiterentwickelt, dass eine Anpassung der Alt-Systeme nicht mehr möglich ist. Wiederaufnahme des Betriebes hätte eine sofortige Non-Compliance und Sperrung aller Zertifikate zur Folge.

1. Statten Sie Ihre kritischen Server in den nächsten Wochen mit neuen Zertifikaten aus (auch vorzeitig).

2. Setzen Sie Automatisierung über ACME um. Jeder Anbieter in TCS wird ACME zur Verfügung stellen. Auch kurzfristig verfügbare Alternative wie Let's Encrypt oder ZeroSSL setzen ACME voraus.

3. Denken Sie daran, dass Ihre Organisation gegebenenfalls die Zertifikatausstellung per CAA auf bestimmte Zertifizierungsstellen eingeschränkt hat: https://doku.tid.dfn.de/de:dfnpki:tcs:caa

   - Prüfen Sie, über welche organisatorischen Prozesse Sie die CAA-Records auf andere Anbieter ändern lassen können.

   - Prüfen Sie für maximale Flexibilität, ob Sie ggf. ganz auf CAA-Records verzichten möchten.

4. Prüfen Sie, ob Sie Anwendungsfälle mit TCS-Zertifikaten realisiert haben, für die die Browserverankerung nicht notwendig ist. Dies betrifft potentiell alle Anwendungsfälle, die nicht der Absicherung von Webservern per HTTPS umfassen. https://doku.tid.dfn.de/de:dfnpki:dfnvereincommunitypki

1. Prüfen Sie, ob Sie Client-Authentifizierung mit User-Zertifikaten einsetzen. Wenn ja: Stellen Sie dies auf die DFN-Verein Community-PKI oder eine andere PKI um, die nicht Bestandteil der Web-PKI ist. (https://doku.tid.dfn.de/de:dfnpki:dfnvereincommunitypki)

2. Prüfen Sie für die Anwendungsfälle S/MIME und Dokumentensignatur, ob diese ggf. auch mit DFN-Verein Community-PKI funktionieren würden. Dies kann z.B. der Fall sein, wenn das Hauptziel die verschlüsselte interne Kommunikation oder interne Verifikation von Dokumentensignaturen ist.

3. Prüfen Sie, ob in Ihrer Organisation S/MIME-Mail-Gateways im Einsatz sind, in denen eine Anbindung an Sectigo umgesetzt wurde. Für diese muss in Zusammenarbeit mit dem Hersteller des Mail-Gateways ebenfalls eine Lösung gefunden werden.

Prüfen Sie, ob in Ihrer Organisation vom Sectigo-spezifischen API Gebrauch gemacht wurde. Dieses spezifische API wird nicht mehr zur Verfügung stehen. https://doku.tid.dfn.de/de:dfnpki:tcs:restapi

Ein neuer Dienstleister wird ebenfalls ein API anbieten. Über die Ausgestaltung können wir naturgemäß derzeit nichts sagen.

Durch eine zeitnahe Erneuerung der Zertifikate vor Ende der Leistungserbringung verschaffen Sie sich mehr Spielraum für Anpassungen in Ihrer Organisation. Dies empfiehlt sich auf jeden Fall für geschäftskritische Zertifikate oder Zertifikate, die bald ablaufen.

Es gibt eine kleine Auswahl an CAs, die ohne Vertragsbeziehung und Kosten Zertifikate ausstellen, u.a. Let's Encrypt und ZeroSSL.

Die Zertifikate aus diesen CAs beinhalten keinen Organisationsnamen (ausschließlich DV, Domain-validated). Die Zertifikatausstellung erfordert stets eine Prüfung der Kontrolle über die Domain, die aber vollautomatisch über ACME durchgeführt wird.

Die Zertifikate sind voll funktionsfähig und sicher.

Der folgende Python-Schnipsel nutzt die Sectigo REST-API, um alle gültigen Serverzertifikate, die der aufrufende Admin im Zugriff hat, zu erneuern.

Voraussetzung: Der aufrufende Admin ist RAO_SSL oder DRAO_SSL und hat das Privileg „autoApproveCertificates“. Dieses Privileg kann in SCM von einem anderen Admin gesetzt werden.

Achtung: Das System von Sectigo erzeugt für jedes Zertifikat potentiell mehrere E-Mails, z.B. an den Original-Antragstellenden. Es können einige Minuten vergehen, bis die Zertifikate ausgestellt worden sind.

Achtung: Der Python-Schnipsel muss noch ergänzt werden, um eine lauffähige Software abzugeben. Dies ist nur eine schnelle Skizze, die mit Sicherheit Fehler enthält.

import datetime
import json
import os
import requests
import string
from urllib.parse import urlparse
import urllib.request

# Stelle sicher, dass der aufrufende Admin das Privileg autoApproveCertificates hat
# und nicht in der Rolle MRAO ist.
def check_admin_role(username,password):

    headers = {
            "password": password,
            "Content-Type": "application/json;charset=utf-8",
            "login": username,
            "customerUri": "DFN",
            "Accept": "application/json"
            }

    # id des Admins ermitteln
    admin_url = 'https://cert-manager.com/api/admin/v1?login='+username
    req = requests.get(admin_url,headers=headers)
    if req.status_code == 200:
       admins=json.loads(req.text)
       if len(admins) > 1:
          print("Fehler: Mehr als ein Admin mit username "+username+" gefunden")
          exit(-1)
       
       # Mit der Admin-id die Admin-Details ermitteln
       admin_url = 'https://cert-manager.com/api/admin/v1/'+str(admins[0]["id"])
       admin_req = requests.get(admin_url,headers=headers)
       if req.status_code == 200:
           admin_details=json.loads(admin_req.text)
           # In den Admin-Details nach dem Privileg autoApproveCertificates suchen 
           if not 'autoApproveCertificates' in admin_details["privileges"]:
              print(admin_details)
              print("")
              print("Fehler: Admin muss das Privileg autoApproveCertificates haben!")
              print("        Rechte des Admins im SCM bearbeiten!")
              exit(-1)
           # Sicherstellen, dass der Admin kein MRAO ist
           for cred in admin_details["credentials"]:
               if cred["role"] == "MRAO":
                   print(admin_details)
                   print("")
                   print("Fehler: Skript nicht als MRAO aufrufen!")
                   exit(-1)
       else:
           print("Fehler: Admin nicht gefunden "+username+" "+admin_req.text)
           exit(-1)
    else:
       print("Fehler: Admin nicht gefunden "+username+" "+req.text)
       exit(-1)

# Alle SSL-Zertifikate, die im Status "Issued" sind, mit Renew erneuern. 
# Dadurch, dass der Admin das Privileg "autoApproveCertificates" hat,
# wird mit kurzer Verzögerung das Zertifikat ausgestellt.
#
# Erstellt eine Datei "renewlist-<Zeitstempel>" mit einer Liste aller sslIds
# der erneuerten Zertifikate.
# Mit den sslIds können die Zertifikate dann abgerufen werden.
def renew(username,password):

    # Admin prüfen
    check_admin_role(username,password)
    headers = {
            "password": password,
            "Content-Type": "application/json;charset=utf-8",
            "login": username,
            "customerUri": "DFN",
            "Accept": "application/json"
            }
    position=0
    count=0
    now = datetime.datetime.now().strftime("%Y%m%d%H%M%S")
    with open("renewlist-"+now,"w+") as outputfile: 
      while True:
        # Alle SSL-Zertifikate mit Status 'Issued' holen. 
        # In 200er Blöcken durch die Zertifikate gehen
        report_url = 'https://cert-manager.com/api/ssl/v1?status=Issued&position='+str(position)+'&size=200'
        req = requests.get(report_url,headers=headers)
        cert_details=json.loads(req.text)
        for cert in cert_details:
            # Zertifikat anhand der sslId erneuern
            renew_url = 'https://cert-manager.com/api/ssl/v1/renewById/'+str(cert["sslId"])
            renew_req = requests.post(renew_url,headers=headers)
            if renew_req.status_code == 200:
                # Die neue sslId des erneuerten Zertifikats in der Ausgabedatei ablegen
                res=json.loads(renew_req.text)
                print(res["sslId"], file=outputfile)
            else:
                print("Fehler für "+cert["sslId"]+" "+cert["commonName"])        
        if len(cert_details) < 200:
             # Keine weiteren Zertifikate, Abbruch der Schleife
             break;
        # Nächster Block     
        position=position+200
    return

Der folgende Python-Schnipsel nutzt die Sectigo REST-API, um in einzelnes ausgestelltes Serverzertifikat herunterzuladen.

Der Eingabe-Parameter sslid ist genau die ID, die das Erneuerungs-Verfahren ausgibt. Das Zertifikat muss bereits ausgestellt sein. Es können einige Minuten vergehen zwischen dem Erneuern und dem Ausstellen.

Achtung: Der Python-Schnipsel muss noch ergänzt werden, um eine lauffähige Software abzugeben. Dies ist nur eine schnelle Skizze, die mit Sicherheit Fehler enthält.

import json
import os
import requests
import string
from urllib.parse import urlparse
import urllib.request

# sslid: herunterzuladendes Zertifikat
# outputdir: Verzeichnis, in dem das Zertifikat abgespeichert werden soll
def collect(sslid,outputdir,username,password):
      headers = {
            "password": password,
            "Content-Type": "application/json;charset=utf-8",
            "login": username,
            "customerUri": "DFN",
            "Accept": "application/json"
            }
      # Zertifikatdetails abfragen, um den commonName zu ermitteln      
      name_url = 'https://cert-manager.com/api/ssl/v1/'+str(sslid)
      req = requests.get(name_url,headers=headers)
      if req.status_code == 200:
        cert_details=json.loads(req.text)
        commonname=cert_details["commonName"] 
        print(cert_details["commonName"]) 
      else:
        print("Fehler "+str(sslid)+": "+req.text)
        exit(-1)
 
      # Herunterladen des Zertifikats
      # format=pemia bedeutet: Zertifikat mit Kette. Issuer nach dem SSL-Zertifikat
      collect_url = 'https://cert-manager.com/api/ssl/v1/collect/'+str(sslid)+'?format=pemia'
      req = requests.get(collect_url,headers=headers)
      if req.status_code == 200:
        print("Erfolg "+str(sslid)) 
        filename=outputdir+'/'+str(sslid)+'_'+commonname+'_chain.pem'
        with open(filename,"w+") as outputfile:
           outputfile.write(req.text)
      else:
        print("Fehler "+str(sslid)+": "+req.text)
 
      return