pki

MobaXterm Custom Certificate Authorities

Written by  on August 3, 2021

Eigene PKI oder CAs in MobaXterm unterbringen geht recht einfach.
Als erstes holen wir eine aktuelle Liste der vertrauenswürdigen CAs als Text (PEM) die auch von Mozilla genutzt werden.
https://github.com/bagder/ca-bundle
Hier können wir frei Root- und Intermediate Zertifikate einfügen oder auch entfernen.
Z.B. von CACert ->
Im MobaXterm Paket, am einfachsten Portable, nehmen wir das File CygUtils.plugin und öffnen es mit z.B. 7-ZIP.
Und ersetzten das file in /etc/pki/tls/certs/ca-bundle.crt.
Das ganze klappt, obwohl das Original File binär (vermutlich DER) kodiert ist und das neue File als Text (PEM).
Ab jetzt vertrauen curl, wget, openssl usw. auch der neuen CA.

Glitch: Let’s Encrypt

Written by  on März 6, 2020

Revoked auch mein Zertifikat
Revoked doch nicht Nur nicht verwendete Zertifikate werden Revoked?
Gut dass ich Buypass ausprobiert habe

certutil ping

Written by  on Juli 21, 2018
certutil -config Contoso8321.example.com\ContosoCA01 -ping
Connecting to Contoso8321.example.com\ContosoCA01 ...
Server "ContosoCA01 " ICertRequest2 interface is alive
CertUtil: -ping command completed successfully.
Connecting to Contoso8321.example.com\ContosoCA01 ...
Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722)
CertUtil: -ping command FAILED: 0x800706ba (WIN32: 1722)
CertUtil: The RPC server is unavailable.
certutil -config - -ping  # Auswahl der Verfügbaren CAs

Berechtigung von Zertifikatsvorlagen exportieren

Written by  on Februar 11, 2018

Haben sich viele Berechtigungen auf eine Zertifikatsvorlage (Certificate Template) angesammelt, will man diese vielleicht auch Mal in eine Liste exportieren ohne diese abzutippen.
Das geht mit certutil.exe

certutil -template
...
    Allow Enroll        Domain\Domain Computers
    Allow Enroll        Domain\ComputerName$
...

Geändertes Browser Verhalten

Written by  on Oktober 28, 2016

Seit Oktober scheint sich das Verhalten von Webbrowsern beim Parsen von SSL/TLS Zertifikaten geändert zu haben. Bei Mozilla Firefox habe ich mir auch die entsprechenden Changes herausgesucht
Bug 585616 – No longer allow IP addresses in SSL server’s common names
Bug 1245280 – don’t fall back to subject common name for name information for new certificates
Kurz gesagt kommt das auf folgendes raus: Wenn es einen Subject Alternativ Name (SAN) gibt, ignoriere den Common Name (CN). Und zusätzlich: Verbiete IP Adressen als CN.
Wenn es bisher ein Zertifikat gab, dass CN=1.2.3.4 hatte und zusätzlich DNS=1.2.3.4 wurde der DNS ignoriert (eine IP Adresse ist kein DNS Name) es gab einen Fallback auf den CN und alle waren glücklich.
Seit Oktober ist es für neue Zertifikate so, dass wie gehabt der DNS Eintrag im SAN ignoriert wird, ein Fallback auf den CN stattfindet, aber die IP Adresse dort auch nicht mehr als Gültig gewertet wird. Das führt dann zu Fehlermeldungen wie: „Das Zertifikat ist nur gültig für 1.2.3.4, Du bist aber auf Seite 1.2.3.4 und das passt nicht zusammen, daher schmeiße ich Dir einen Zertifikatsfehler um die Ohren.“
Bei Mozilla heißt es dazu:

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates.


Wie macht man das jetzt richtig? Im SAN muss für eine IP Adresse das Primitive „IP“ verwendet werden und nicht „DNS“, dann klappt auch die Validierung wieder!

Zertifizierungsstellen: WoSign und StartCom verlieren Apples und Mozillas Vertrauen

Written by  on Oktober 27, 2016

Es mag ja an eine Verschwörungstheorie grenzen, aber Mozilla versucht mit allen Mitteln, die einzige CA aus dem Geschäft zu drängen, die kostenlose SSL/TLS Zertifikate für alle ausstellt. Ich höre den Aufschrei, die haben doch Let’s encrypt? Eben, genau das ist vermutlich der Grund, warum sie keine anderen kostenlos CAs neben sich haben wollen. Und es bleibt dabei, Let’s encrypt ist eben nicht für alle. Jeder der keinen Root-Zugriff auf seinen Webspace hat, bekommt keinen Client. Sich mit diversen Workarounds zu beschäftigen, ist doch relativ aufwändig, wenn man bedenkt, dass das dann alle 90 Tage wieder von vorne ansteht. Und Umlautdomains, warum sollte das Mozilla Projekt Let’s encrypt denn Umlaute (IDN-Domains) Unterstützen. Es muss ja ein wirklich furchtbarer Aufwand sein, Domains die mit xn-- beginnen zuzulassen. Was bitteschön soll da jemand für ein Schindluder betreiben?
Kurz gesagt, wer auf mein Blog über SSL zugreift, für den wird es zumindest mit Firefox in Bälde finster werden. Was soll ich sagen? So ist es eben. Ich würde ja sogar auf CACert wechseln… wenn die denn IDN Domains unterstützen würden.

Zertifizierungsstellen WoSign und StartCom verlieren Apples und Mozillas Vertrauen

Zertifizierungsstellen Bei WoSign und StartCom rollen Koepfe

Wosign Startcom separated

Zertifikats Schmu bei WoSign und StartCom Mozilla macht Ernst

Zitat des Tages

Written by  on September 15, 2016

When a certificate contains alternative names, all common names are ignored. Newer certificates produced by CAs may not even include any common names. For that reason, include all desired hostnames on the alternative names list.

Disaster Recovery Plan

Written by  on August 25, 2016

[The] disaster recovery plan should include everything required to get your PKI environment back up and operational, including (1) how and where backup files are stored, (2) how backups can be retrieved, (3) what hardware is needed to access them, (4) where to get the hardware if if the primary systems are destroyed, and (5) where your operating system software and application software is stored and how to reinstall all of the pieces.

Zitat des Tages

Written by  on August 23, 2016

What both disaster recovery and business continuity have in common is the need for testing and verification that the testing actually accomplishes the goals of DR or BC. A regular test plan must be performed and evaluated for both DR and BC. Without regular testing, you will never know that the data you thought were backed up can actually be restored or that your failover data center will come online when a disaster strikes. If you do not test your DR and BC plans, your PKI organization will fail when it is needed most. Backups can and do fail occasionally. If you do not test restoring your backups, you will never know if the data will be available in a crisis situation.

Jeff Stapleton & W. Clay Epstein; Security without Obscurity: A Guide to PKI Operations

Zitat des Tages

Written by  on August 21, 2016

Backups can and do fail occasionally.

Jeff Stapleton, W. Clay Epstein; Security without Obscurity: A Guide to PKI Operations