Protokoll für verschlüsselte und authentifizierte Verbindungen über TCP.

• SSL → Secure Socket Layer
• TLS → SSL 3.1 → Transport Layer Security

• basierend auf TCP
• steht zwischen Schicht 4 und 5 (4.5 :))

• Startssl.com
• Günstige CA
• Kostenlose Level-1-Zertifikate
• in allen gängigen Browsern vorinstalliert

• Nach Registrierung wird ein Zertifikat automatisch im Browser installiert welches zukünftig als Authentifizierung gegenüber dem Dienst dient (statt Psswort)

• SSL-Suite zum Erstellen und Verwalten von Keys, Zertifikaten und CAs
• Mehr unter openssl

• ähnlich OpenSSL
• eigentständige Implementierung (inkl. eigenständiger Bibliothek)

• das Zertifikat (als Text) hat eine Sektion „Authority Key Identifier“ (der Fingerprint des Schlüssels der dieses Zertifikat signiert hat):

X509v3 Authority Key Identifier: 
                keyid:08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7

• das Zertifikat einer CA hat das Gegenstück „Subject Key Identifier“ (der Fingerprint des Schlüssels der zum Zertifikat gehört):

 X509v3 Subject Key Identifier: 
                08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7

Die Beiden Key Identifier stimmen überein und besagen das das Zertifikat durch die CA zu der das andere Zertifikat gehört signiert worden ist.
Natürlich hat ein „normales Zertifikat“ auch einen Subject Key Identifier und ein CA-Zertifikat auch einen Authority Key Identifier.

• das Zertifikat hat eine Basic Constraints Section mit gesetztem CA-Flag:

  X509v3 Basic Constraints: critical
                CA:TRUE

• eine Key Usage Section mit „Certificate Sign“ Flag:

 X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

• ein Intermediate-Zertifikat hat eine „Authority Key Identifier“ Sektion die auf den Subject-Key eines anderen Zertifikates (der CA die das Zertifikat der intermediate CA signiert hat → also die nächst höhere Station in der Chain)
• ein Root-CA-Zertifikat hat keine Sektion „Authority Key Identifier“ und Subject- und Issuer-Eintrag sind identisch
  • das kommt daher da das Zertifikat self-signed ist (es gibt ja keine höhere Stelle die es signiert haben könnte)

• SHA1 ist in aktuellen Versionen von OpenSSL per Default deaktiviert als Signing-Algorithmus
• Auch wenn man die entsprechenden Signatur-Algorithmen explizit angibt werden sie in openssl nicht genutzt (bis man unten stehende Option setzt)
• man kann es wahrscheinlich in der openssl.conf systemweit aktivieren

• man kann openssl folgenden Parameter übergeben:

"CipherString" => "DEFAULT@SECLEVEL=1"

• viele Programme die openssl benutzen kennen einen Config-Parameter „ssl.openssl.ssl-conf-cmd“ oder ähnlich benannt
  • darüber kann man openssl Parameter mitgeben (ohne dafür eine explizite Option zu brauchen)
• im Falle von lighttpd sieht das so aus:

ssl.openssl.ssl-conf-cmd=("CipherString" => "DEFAULT@SECLEVEL=1")

• da die Root-CAs auf der Gegenseite schon vorhanden sind brauchen sie nicht gesendet werden (können aber), die Auflösung funktioniert auch ohne
• alle Intermediate-Certifacates + das Host-Certificate müssen gesendet werden
  • weil die sind ja nicht auf der Gegenseite vorhanden und die Chain kann sonst nicht aufgebaut werden