Archiv des Autors: Juergen Brauckmann

Java RA-Oberfläche Version 3.7.1

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.7.1 hier herunterladen:

guira-3.7.1.zip

guira-3.7.1.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Gegenüber der Version 3.7 umfasst die Version 3.7.1 die folgenden Änderungen:

  • In der Zertifikat-Übersichtsliste die Spalte ‚EMail‘ anzeigen, aber die Spalte ‚OK‘ ausblenden.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

Konfiguration

Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.

(Jürgen Brauckmann, 16.05.2022)

Java RA-Oberfläche Version 3.7

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.7 hier herunterladen:

guira-3.7.zip

guira-3.7.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Gegenüber der Version 3.6 umfasst die Version 3.7 die folgenden Änderungen:

  • Spalte ‚Kontakt-Abtlg‘ in den Übersichtslisten hinzugefügt.
  • Start-Skripte angepasst, so dass abhängige jars einzeln vorliegen, damit die Signaturprüfung auch mit einem OracleJDK durchgeführt werden kann.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

Konfiguration

Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.

(Jürgen Brauckmann, 12.04.2022)

SOAP-Client Version 4.4

Das Bundle mit der Dokumentation und der Java-Client-Bibliothek der SOAP-Schnittstelle der DFN-PKI steht nun in einer neuen Version für JDK >= 11 bereit: https://info.pca.dfn.de/doc/soapclient-bundle-4.4.tar.gz

Änderungen der Version 4.4 gegenüber 4.3:

  • Aktualisierung der enthaltenen Abhängigkeiten

Für Entwicklungsarbeiten empfehlen wir dringend, dass Sie unsere Test-PKI verwenden. Sprechen Sie uns bitte an, um einen Zugang zu erhalten. Kontakt: mailto:dfnpca@dfn-cert.de

Bitte beachten Sie, dass Sie bei der Implementierung von eigenen Systemen zum Bezug von Zertifikaten aus der DFN-PKI Global unbedingt die Vorgaben der Zertifizierungsrichtlinie und des Dokumentes Pflichten der Teilnehmer einhalten müssen. Bitte besprechen Sie Ihr Projekt vorab mit uns. Kontakt: mailto:dfnpca@dfn-cert.de

(Jürgen Brauckmann, 12.04.2022)

Einführung in die Automatisierung mit GÉANT TCS

Praktisch alle Funktionen von GÉANT TCS, die über die Web-Oberfläche angeboten werden, sind auch über ein REST-API verfügbar. Mit diesem API können verschiedenste Aufgaben mit eigenen Werkzeugen ausgeführt werden, ohne den Weg über die manchmal langsame oder auch unübersichtliche Web-Oberfläche gehen zu müssen. Beispiele für nützliche Aufgaben:

  • Ausstellung von Serverzertifikaten
  • Eintragen von neuen Domains
  • Erzeugen von ACME-Accounts
  • Monitoring des Validierungszustandes von Domains

Eine Dokumentation des APIs ist verfügbar über: https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE

Die hier skizzierten Beispiele sollen keine fertige Lösung darstellen, sondern einen Eindruck von den Möglichkeiten des TCS REST-APIs vermitteln. Zum Nachvollziehen der Beispiele muss unbedingt die Dokumentation des APIs herangezogen werden.

Aufruf-Schema

Wie bei REST-APIs üblich, müssen die Ressourcen per HTTP GET oder POST angesprochen werden. Bei jedem Aufruf ist ein Header zu übermitteln, der auch Nutzername/Passwort zur Authentifizierungs enthält:

    login: <login>
    password: <Passwort>
    customerUri: DFN
    Content-Type: application/json;charset=utf-8

Die customerUri ist für alle Teilnehmer der DFN-PKI identisch und hat schlicht den Wert „DFN“.

login und password sind die Zugangsdaten eines RAO- oder DRAO-Accounts aus TCS (angelegt in https://cert-manager.com/customer/DFN). Es ist möglich, einen Account so zu beschränken, dass er nur über das REST-API und nicht über die Web-Oberfläche genutzt werden kann, siehe hierzu den Punkt „Api-Only-User“ unter https://doku.tid.dfn.de/de:dfnpki:tcsfaq#admins_rollen_privilegien. Da im REST-API aber nicht weniger Funktionalität zur Verfügung steht als über die Web-Oberfläche, ist diese Einschränkung eher kosmetischer Natur.

Beispiel der Grundstruktur für die Linux-Shell mit curl:

curl 'https://cert-manager.com/api/<....>' -i -X POST \
    -H "login: <login>" \
    -H "password: <password>" \
    -H "Content-Type: application/json;charset=utf-8" \
    -H "customerUri: DFN"
    -d "{...}"

Beispiel der Struktur für Python:

d = {
    "xyz": "value"
}

url = 'https://cert-manager.com/api/....'
headers = {
    "login": username,
    "password": password,
    "Content-Type": "application/json;charset=utf-8",
    "customerUri": "DFN"
}
req = requests.post(url,data=json.dumps(d),headers=headers)
# Antwort dann in req.json()

Beispiel: Ausstellung von Server-Zertifikaten

Bevor das API zum Ausstellen von Zertifikaten genutzt werden kann, muss in den Einstellungen der Organisation unter ☰→Organizations→Edit→Certificate Settings jeweils bei SSL Certificates und Client Certificates der Punkt „Web API“ angekreuzt werden. Zusätzlich wird die Eingabe eines Secret Keys erzwungen, der aber für die Nutzung des REST-API nicht benötigt wird.

Organisations-ID und Web API-Einstellung

Es werden zwei weitere Parameter benötigt:

  • Die ID der Organisation, in der das Zertifikat ausgestellt werden soll, kann man direkt in cert-manager ablesen unter ☰→Organizations→Edit. Der blau hinterlegte Wert rechts neben dem Organisationsnamen ist die gewünschte ID.
  • Die ID der Zertifikatprofile muss mit einem Aufruf des REST-API ermittelt werden. Hierzu wird der folgende Aufruf durchgeführt, im Beispiel in einer Linux-Shell mit curl:
  echo -n Password:
  read -s PASS
  echo
  curl 'https://cert-manager.com/api/ssl/v1/types' -i -X GET \
      -H "login: <login>" \
      -H "password: $PASS" \
      -H "Content-Type: application/json;charset=utf-8" \
      -H "customerUri: DFN"

Ausgabe:

[{"id":15860,"name":"OV SSL","description":"","terms":[365],"keyTypes":{"RSA":["2048","3072","4096","8192"],"EC":["P-256","P-384"]},"useSecondaryOrgName":false},
{"id":15862,"name":"Wildcard SSL","description":"","terms":[365],"keyTypes":{"RSA":["2048","3072","4096"],"EC":["P-256","P-384"]},"useSecondaryOrgName":false},
{"id":15863,"name":"OV Multi-Domain","description":"","terms":[365],"keyTypes":{"RSA":["2048","3072","4096"],"EC":["P-256","P-384"]},"useSecondaryOrgName":false},
{"id":15865,"name":"EV Anchor","description":"","terms":[395],"keyTypes":{"RSA":["2048","3072","4096","8192"]},"useSecondaryOrgName":false},
usw.

Es ist zu empfehlen, dass Profil OV Multi-Domain zu verwenden. In der Ausgabe findet man hierzu die  ID 15863.

Mit der ermittelten Organisations- und der Profil-ID wird nun nur noch ein CSR benötigt, der z.B. mit openssl erzeugt wurde. Mit dem folgendem Aufruf kann der CSR eingereicht werden:

curl 'https://cert-manager.com/api/ssl/v1/enroll' -i -X POST \
    -H "login: <login>" \
    -H "password: <passwort> \
    -H "Content-Type: application/json;charset=utf-8" \
    -H "customerUri: DFN"
    -d "{\"orgId\":<Organisations-ID>,\"subjAltNames\":\"\",\"certType\":15863,\"numberServers\":0,\"serverType\":-1,\"term\":365,\"comments\":\"\",\"externalRequester\":\"\",\"customFields\": [],\"csr\":\"-----BEGIN CERTIFICATE REQUEST-----\nMIICtDCCAZwCAQAwbzELMAkGA1UEBhMCREUxEDAOBgNVBAgMB0hhbWJ1cmcxEDAO\nBgNVBAcMB0hhbWJ1cmcxHzAdBgNVBAoMFkRGTiBDRVJ....vfoLQu9d\n-----END CERTIFICATE REQUEST-----\n\"}"

Ausgabe:

{"sslId":<SSLID>,"renewId":"<renewId>"}

Damit ist der Antrag im cert-manager eingegangen. Ob das Zertifikat sofort ausgestellt wird oder noch ein manueller Eingriff im cert-manager notwendig ist, hängt von den Rechten des Login-Users ab: Wenn der Login-User in seinem Profil „Allow SSL auto approve“ gesetzt hat, wird das Zertifikat sofort ausgestellt.

Nach Ausstellung des Zertifikats kann dieses mit der SSLID aus der Ausgabe abgerufen werden:

curl '"https://cert-manager.com/api/ssl/v1/collect/<SSLID>/base64" -i -X GET \
     -H "login: <login>" \
     -H "password: <passwort> \
     -H "Content-Type: application/json;charset=utf-8" \
     -H "customerUri: DFN"

Beispiel: Eintragung einer Domain

Um eine Domain automatisiert in SCM einzutragen, benötigt man wieder die Organisations-ID, ablesbar beispielsweise im cert-manager unter Organisation->Edit. Mit der Organisations-ID kann direkt eine Domain eingetragen und die Delegation für die einzelnen Zertifikattypen an die Organisation eingeleitet werden:

curl 'https://cert-manager.com/api/domain/v1' -i -X POST \
    -H "login: <login>" \
    -H "password: <passwort> \
    -H "Content-Type: application/json;charset=utf-8" \
    -H "customerUri: DFN"
    -d '{"name":"<Domainname>","active":true,"delegations":[{"orgId": "<Organisations-ID>","certTypes":["CodeSign","SMIME","SSL"]}]}'

Rückgabewert ist ein HTTP-Status 201 und ein Location-Header mit der ID der neuen Domain, Beispiel:

HTTP/1.1 201 Created
Location: https://cert-manager.com/api/domain/v1/481

Wenn gewünscht, kann für die Domain anschließend eine Validierung durchgeführt werden. Hierzu muss zunächst ein Aufruf zum Starten der gewünschten Methode (HTTP, HTTPS, CNAME oder EMAIL) durchgeführt werden:

https://cert-manager.com/api/dcv/v1/validation/start/domain/http
https://cert-manager.com/api/dcv/v1/validation/start/domain/https
https://cert-manager.com/api/dcv/v1/validation/start/domain/cname
https://cert-manager.com/api/dcv/v1/validation/start/domain/email

Es muss dabei gepostet werden:

{„domain“:“<Domainname>“}

Der Rückgabewert des Start-Aufrufs ist ein Geheimnis, dass an der angezeigten Stelle per HTTP/HTTPS oder DNS verfügbar gemacht werden muss (Details müssen in der Dokumentation nachgeschlagen werden), bzw. eine Auswahl an E-Mail-Adressen für EMAIL DCV.

Im zweiten Schritt wird mit einem Aufruf von „submit“ signalisiert, dass das Geheimnis von Sectigo per HTTP/HTTPS oder DNS überprüft werden kann bzw. an eine spezifizierte E-Mail-Adresse eine Challenge gesendet werden soll:

https://cert-manager.com/api/dcv/v1/validation/submit/domain/http
https://cert-manager.com/api/dcv/v1/validation/submit/domain/https
https://cert-manager.com/api/dcv/v1/validation/submit/domain/cname

Es muss dabei wieder gepostet werden:

{„domain“:“<Domainname>“}

 

Oder für EMAIL-DCV an https://cert-manager.com/api/dcv/v1/validation/start/domain/email:

{„domain“:“<Domainname>“, "email":"<Email>"}

Das System versucht daraufhin im Hintergrund die Validierung durchzuführen, also z.B. eine HTTP/HTTPS/DNS-Abfrage auf <Domainname> zur Prüfung des Geheimnisses zu machen.

Der Status kann mit einem einfachen POST an https://cert-manager.com/api/dcv/v2/validation/ abgefragt werden:

{„domain“:“<Domainname>“}

 

Beispiel: Automatisiertes Erzeugen eines ACME-Accounts

Um ACME-Accounts per API zu erzeugen und für die Ausstellung von Zertifikaten nutzen zu können, muss in drei Schritten vorgegangen werden.

Im ersten Schritt wird der Account angelegt mit einem POST an https://cert-manager.com/api/acme/v1/account mit den folgenden Daten:

{"name": "<Beliebig gewählter Account-Name>",
"acmeServer": "https://acme.sectigo.com/v2/OV",
"organizationId": "<Organisations-ID>"
}

Die ID des neu erzeugten Accounts wird in einem Location-Header zurückgeliefert.

Im Anschluss müssen dem Account Domains hinzugefügt werden. Dies geschieht über einen POST an https://cert-manager.com/api/acme/v1/account/<AccountId>/domains mit den folgenden Daten:

{ "domains": [ {"name":"<domain1>"},{"name":"<domain2>"}...]}

Ist dies geschehen, können die Parameter für das External Account Binding abgerufen werden, die für die Einbindung des ACME-Accounts in die Client-seitigen Werkzeuge wie certbot benötigt werden. Dies geschieht mit einem GET an https://cert-manager.com/api/acme/v1/account/<AccountId>

Die umfangreiche Rückgabe hat die folgende Struktur:

{"id":<Account-ID>, "name":"<Gewählter Account-Name>","status":"pending",
"macKey":"Qdr1P53XA9G3HL_....._WyqUNsBDwPtXU6",
"macId":"WyqUNsBDwPtXU6_...",
"acmeServer":"https://acme.sectigo.com/v2/OV",
"organizationId":<Organisations-ID>,"certValidationType":"OV","accountId":"z-PYNnsxepUVwFWs-qeTfA","ovOrderNumber":<ordernumber>,"contacts":"","evDetails":{},"domains":[{"name":"<domain1"},...]}

Die in der Rückgabe enthaltenen Parameter macKey und macId müssen beim Aufruf von z.B. certbot als Parameter –eab-hmac-key und –eab-kid übergeben werden.

Beispiel: Monitoring des Validierungszustandes von Domains

Es kann nützlich sein, den Status, den die wichtigsten Domains im cert-manager haben, in ein Monitoring zu integrieren.

Der Status kann mit der Ressource https://cert-manager.com/api/domain/v1/<Domain-ID> abgefragt werden. Die Domain-ID kann, soweit sie noch nicht bei der Anlage der Domain gespeichert wird, nur über eine Schleife mit Auflistung über alle eingetragenen Domains ermittelt werden. Die Auflistung muss in Blöcken durchgeführt werden:
https://cert-manager.com/api/domain/v1?size=<Blockgröße>&position=<Blockstart>

Hat man in den zurückgegebenen Elementen den gesuchten Domain-Namen gefunden, kann mit der zugehörigen Domain-ID der Status abgefragt werden: https://cert-manager.com/api/domain/v1/<Domain-ID>

Beispielhaftes Vorgehen als Python-Skizze:

# domains_to_check: Liste mit zu überwachenden Domains
def monitor_domains(login,password,domains_to_check):
    headers = {
        "password": password,
        "Content-Type": "application/json;charset=utf-8",
        "login": login,
        "customerUri": "DFN"
    }
    # Ermitteln der Anzahl der eingetragenen Domains:
    url = 'https://cert-manager.com/api/domain/v1/count'
    req = requests.get(url,headers=headers)
    if req.status_code != 200:
        print("CRIT: cannot get domain count "+domain+": "+str(req.status_code)+" "+req.text)
        return(2)
    count=req.json()["count"]

    # Loop über alle Domains. Das API erzwingt ein blockweises Vorgehen über die Parameter size und position
    for i in range(int(count/50)+1):
        position=i*50
        size=50
        url = 'https://cert-manager.com/api/domain/v1?size='+str(size)+'&position='+str(position)
        req = requests.get(url,headers=headers)
        if req.status_code != 200:
             print("CRIT: cannot get domain list with "+url+": "+str(req.status_code)+" "+req.text)
             return(2)
        # Einen Block erhalten, Schleife
        domainlist=req.json()
        for domain in domainlist:
            if domain["name"] in domains_to_check:
                # Wenn die Domain geprüft werden soll, mit der eben erhaltenen ID die Domain-Details abrufen.
                url = 'https://cert-manager.com/api/domain/v1/'+str(domain["id"])
                req = requests.get(url,headers=headers)
                if req.status_code != 200:
                    print("--CRIT: cannot get info of domain "+domain["name"]+" url:"+url+": "+str(req.status_code)+" "+req.text)
                    continue
                # Delegationszustand prüfen
                if req.json()["delegationStatus"] != 'ACTIVE':
                    print("--CRIT: delegationStatus of domain "+domain["name"]+" is not ACTIVE: "+req.json()["delegationStatus"])
                # Domain überhaupt Activ?
                if req.json()["state"] != 'ACTIVE':
                    print("--CRIT: state of domain "+domain["name"]+" is not ACTIVE: "+req.json()["state"])
                # Validierungszustand
                if req.json()["validationStatus"] != 'VALIDATED':
                    print("--CRIT: validationStatus of domain "+domain["name"]+" is not VALIDATED: "+req.json()["validationStatus"])

                # Ablaufdatum des Validierungszustand prüfen
                if "dcvExpiration" in req.json():
                    expdate=req.json()["dcvExpiration"]
                    expdate_obj = datetime.strptime(expdate,'%Y-%m-%d')
                    # Differenz zum aktuellen Datum bilden
                    now_obj = datetime.now()
                    ddiff=abs(expdate_obj-now_obj).days

                    if ddiff < 5:
                        # Weniger als 5 Tage gültig?
                        print("--CRIT: domain "+domain["name"]+" validated until "+expdate+", less than 5 days left!")
                    elif ddiff < 30:
                        # Weniger als 30 Tage gültig?
                        print("--WARN: domain "+domain["name"]+" validated until "+expdate+", less than 30 days left!")
                    else:
                        print("--OK: domain "+domain["name"]+" active and validated until "+expdate)

(Jürgen Brauckmann, 21.02.2022)

GÉANT Trusted Certificate Services

In den vergangenen Monaten startete in der DFN-PKI die Einführung von GÉANT Trusted Certificate Services (TCS).

In den nun erschienenen DFN-Mitteilungen Ausgabe 100 findet sich ein Überblicksartikel über die Weiterentwicklung der DFN-PKI mit TCS: https://dfn.de/wp-content/uploads/2021/11/DFN_100_download.pdf#page=46

TCS ist ein PKI-Angebot, dass der DFN-Verein seit 2021 über GÉANT bezieht. Einen Überblick über den Dienst finden Sie bei GÉANT unter: https://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx

Es gibt eine ausführliche TCS FAQ: https://doku.tid.dfn.de/de:dfnpki:tcsfaq

TCS wird das bisherige DFN-PKI Sicherheitsniveau „Global“ ablösen. Neue Server- und Nutzerzertifikate mit Browser-Verankerung können nach einer Übergangsfrist ausschließlich aus TCS bezogen werden. Für Serverzertifikate wird der Übergang Ende 2022 stattfinden. Für Nutzerzertifikate reicht die Frist bis Ende 2023.

(Jürgen Brauckmann, 16.12.2021)

ETSI-Audit 2021 abgeschlossen

Auch dieses Jahr wurde die DFN-PKI auditiert, um die Erfüllung der Anforderungen von ETSI EN 319 411-1 und den Baseline Requirements des CA/Browserforums nachweisen zu können. Wie bei jedem Audit, der bisher durchgeführt wurde, wurde bei einer geringen Anzahl von Teilnehmern die Arbeit des Teilnehmerservice untersucht. Wir bedanken uns bei allen Einrichtungen, die wie auch in den letzten Jahren mit ihrer guten Arbeit ein erfolgreiches Audit der DFN-PKI ermöglicht haben!

Die zugehörige Zertifizierungsurkunde ist Anfang Dezember vom TÜViT veröffentlicht worden: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/67133UD.pdf

Die sogenannte Audit Attestation, die eine Zusammenfassung der Ergebnisse für die Root-Programme der Browser und Betriebssystemhersteller enthält, steht ebenfalls zur Verfügung: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2021113001_DFN-Verein_Certification_Authority_2_V1.0.pdf

(Jürgen Brauckmann, 16.12.2021)

Version 10 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 01.10.2021 tritt die Zertifizierungsrichtlinie 10 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 10:

      • Titel und Fußzeile: Versionsnummer und Datum
      • 1.2: OIDs
      • 3.2.2: Fußnote korrigiert
      • 10: Referenz IANA Special-Purpose Addresses an Ballot SC48 angepasst

Die Version 10 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 01.10.2021, beinhaltet folgende Änderungen:

      • Titel und Fußzeile: Versionsnummer und Datum
      • 1.2: OIDs

Die neuen Dokumente finden Sie unter den folgenden URLs:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V10.pdf

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V10.pdf

Mit Änderungsmarkierungen:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V10_redline.pdf

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V10_redline.pdf

(Jürgen Brauckmann, 14.09.2021)

Version 9 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 30.06.2021 tritt die Zertifizierungsrichtlinie 9 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 9:

    • Titel und Fußzeile: Versionsnummer und Datum.
    • 1.2: OIDs
    • 3.1.1: SN, GN, pseudonym; CN single-value
    • 3.1.2: SN, GN, pseudonym; CN single-value
    • 3.1.3: Attribut pseudonym
    •  4.2.1: Änderung der Frist zur Wiederverwendung von Daten über die Berechtigungsprüfung bei Domains und IP-Adressen auf 398 Tage ab 1.10.2021
    • 4.9.12: Methoden zum Nachweis der Kompromittierung eines privaten Schlüssels
    • 4.9: Tippfehler entfernt, 9.6.5: Tippfehler Kapitelüberschrift beseitigt, 3.1.2: Tippfehler entfernt

Die Version 9 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 30.06.2021, beinhaltet folgende Änderungen:

      • Titel und Fußzeile: Versionsnummer und Datum
      • 1.2: OIDs

Die neuen Dokumente finden Sie unter den folgenden URLs:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V9.pdf

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V9.pdf

Mit Änderungsmarkierungen:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V9_redline.pdf

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V9_redline.pdf

(Jürgen Brauckmann, 14.06.2021)

Java RA-Oberfläche Version 3.6

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.6 hier herunterladen:

guira-3.6.zip

guira-3.6.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Gegenüber der Version 3.5.1 umfasst die Version 3.6 (25.05.2021) folgende Änderungen:

  • Unterstützung der DN-Attribute givenName, surname und pseudonym in Assistenten.
  • Fehlermeldung bei fehlender PKCS#11-Library beim Einrichten einer CA verbessert.
  • Fehler beim Sperren von Zertifikaten in Assistenten bei Verwendung des Kommandos ‚NewAndApprove‘ behoben.
  • Fehler beim Export von Zertifikaten (unter MacOS) behoben.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

Konfiguration

Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.

(Jürgen Brauckmann, 07.06.2021)

Umstellung notwendig: Änderungen am SOAP-API

Einige Anwender der DFN-PKI nutzen die SOAP-API (https://blog.pki.dfn.de/tag/soapclient-releases/) zur Entwicklung von eigenen Systemen. An diesen Eigenentwicklungen müssen nun bis spätestens November 2021 Anpassungen vorgenommen werden, um die folgenden Änderungen umzusetzen.

Nicht betroffen sind Anwender, die ausschließlich die Java RA-Oberfläche und die Web-Antragsseiten nutzen.

Änderungen bei newRequest()

Der Subject-DN im PKCS#10-Request, der bei newRequest() übergeben wird, muss für Nutzer-und Pseudonymzertifikat anders aufgebaut werden.

Für Nutzerzertifikate: Es müssen zusätzliche DN-Attributen SN (surname, Nachname) und GN (givenName, Vorname) übergeben werden. Beispiel:

CN=Martha Musterfrau,GN=Martha,SN=Musterfrau,O=Musterorganisation,L=Musterstadt,ST=Musterbundesland,C=DE

Anträge für Nutzerzertifikate ohne CN, GN und SN werden an November 2021 nicht mehr angenommen.

Für Pseudonymzertifikate: Es muss ein zusätzliches DN-Attribut pseudonym übergeben werden. Der Wert soll wie der CN sein, aber ohne das führende „PN:“ oder „PN – „. Beispiel:

CN=PN: Mein Pseudonym,pseudonym=Mein Pseudoynm,O=Musterorganisation,L=Musterstadt,ST=Musterbundesland,C=DE

Anträge ohne CN und pseudonym, wenn der CN mit „PN:“ oder „PN – “ beginnt, werden ab November 2021 nicht mehr angenommen.

Für Gruppenzertifikate (Kennzeichnung „GRP:“ bzw. „GRP – „) und Serverzertifikate ändert sich nichts.

Selbstverständlich müssen die neuen Regeln auch bei der Verwendung von setRequestParameters() bzw. setExtendedRequestParameters() beachtet werden.

Optionale Übergabe des Subject-DN als separatem Parameter

Als weitere Änderung kann newRequest() optional auch zusätzlich der Subject-DN übergeben
werden. Dieser Wert überschreibt dann den Subject-DN aus dem übergebenen PKCS#10-Request.

Änderungen bei newRevocationRequest()

Der Parameter Reason in newRevocationRequest() darf in Zukunft nur noch die Werte
1, 3, 4 oder 5 annehmen. Die Bedeutung:

1, keyCompromise: Dieser Sperrgrund signalisiert, dass der zum Zertifikat
gehörende geheime Schlüssel kompromittiert (offengelegt) wurde oder
andere Aspekte der durch den Zertifikatnamen (SubjectDN) beschriebenen
Entität kompromittiert wurden.

3, affiliationChanged: Dieser Sperrgrund signalisiert, dass der Zertifikatname
(SubjectDN) oder andere Informationen im Zertifikat nicht mehr den
aktuellen Tatsachen entsprechen, etwa weil sich Namen,
E-Mail-Adressen, Funktionsrollen oder Zugehörigkeiten geändert haben,
dass aber gleichzeitig kein Grund für einen Verdacht besteht, dass der
zum Zertifikat gehörende geheime Schlüssel kompromittiert wurde.

4, superseded: Dieser Sperrgrund signalisiert, dass das Zertifikat von
einem neueren Zertifikat abgelöst wurde, dass aber gleichzeitig kein
Grund für einen Verdacht besteht, dass der zum zu sperrenden
Zertifikat gehörende geheime Schlüssel kompromittiert wurde.

5, cessationOfOperation: Dieser Sperrgrund signalisiert, dass das Zertifikat
nicht länger für die Zwecke eingesetzt wird, für die es ausgestellt
wurde, dass aber gleichzeitig kein Grund für einen Verdacht besteht,
dass der zum Zertifikat gehörende geheime Schlüssel kompromittiert
wurde.

Im soapclient gibt es hierfür die folgende neue Methode:

DFNCERTPublic.newRevocationRequest(int RaID,
BigInteger Serial, de.dfncert.enums.RevocationReason Reason, String Pin)

bzw.

DFNCERTRegistration.newRevocationRequest(BigInteger Serial, de.dfncert.enums.RevocationReason Reason)

Die Sperrgründe werden als de.dfncert.enums.RevocationReason übergeben:

RevocationReason.KEY_COMPROMISE
RevocationReason.AFFILIATION_CHANGED
RevocationReason.SUPERSEDED
RevocationReason.CESSATION_OF_OPERATION

Diese eingeschränkten Sperrgründe müssen auch bei einem Aufruf von setRevocationInfo() berücksichtigt werden.

Zeitplanung

Die aktuelle Schnittstelle (Stand Februar 2021) ist noch voll abwärts-kompatibel. Ab November 2021 wird allerdings die Verwendung der neuen DN-Parameter in newRequest(), setRequestParamaters() und setExtendedRequestParameters() und der neuen Sperrgründe in newRevocationRequest() und setRevocationInfo() verpflichtend.

 

(Jürgen Brauckmann, 18.2.2021)