Fra.nkSteidl.de

Eine CA mit OpenSSL

Inhalt:

Erstellen einer CA
Editieren der openssl.cnf
Anlegen der benötigten Verzeichnisse
Erzeugen der Zufallszahlen
Erstellen der RootCA
Erstellen der SubCAs

Handhabung von Zertifikaten
Erstellen eines Server-Zertifikats
Erstellen eines User-Zertifikats
Widerrufen von Zertifikaten
Generierung einer Certificate Revocation List (CRL)

Integration in Apache


Bemerkungen

Dies ist eine Quick-and-Dirty Anleitung, wie man unter Linux eine CA aufsetzt. Hauptgrund war das Erstellen eines Nachschlagewerks für die doch recht kryptischen openssl-Befehle. Es gibt sicherlich auch Hilfs-Skripte, die einem die Arbeit erleichtern, diese werden allerdings nicht erwähnt.

Grundlage dieses How-To's ist das OpenSSL Handbuch der Universität Kiel, zu finden unter
http://www.dfn-pca.de/certify/ssl/handbuch/ossl095/ossl095.html

Es wird nicht auf die organisatorischen Anforderungen an eine CA eingegangen. Eine gewöhnliche PKI (Public Key Infrastucture) für den Einsatz in sicherheitskritischen Umgebung erfordert viel organisatorische Arbeit, worauf hier auch nicht eingegangen wird. In dieser Anleitung wird davon ausgegangen daß ein Administrator eine CA und deren SubCAs auf der selben Maschine betreibt, und dieser Administrator die einzige Instanz zum Erstellen der CAs, der Zertifikate und zum Widerrufen von Zertifikaten ist.



Installation der Software

Bei Debian Linux ist das Installieren von OpenSSL ein einziger Befehl:
 apt-get install openssl 
Bei anderen Distributionen oder beim eigenständigen Kompilieren der Software sind deutlich mehr Schritte notwendig, auf die hier nicht eingegangen werden soll.
Das Hauptverzeichnis der CA ist
/usr/lib/ssl
ab hier werden alle Daten verwaltet.
Entsprechend sicher müssen die Berechtigungen der einzelnen Unterverzeichnisse sein, wenn man bedenkt, daß eine CA für mehrere Jahre erstellt wird und ebenso lange sicher sein soll.


Editieren der openssl.cnf

Alle Grundeinstellungen der CA werden in dieser Konfigurationsdatei gemacht. Folgende ausgewählte Einträge sind wichtig:
 HOME                    = /usr/lib/ssl 
Hier wird das Home-Verzeichnis der gesamten CA angegeben (s.o.)
####################################################################
[ ca ]
default_ca      = UserCA            # The default ca section
####################################################################

Für jede SubCA muß folgender Abschnitt definiert sein. Diese Namen werden bei der Signierung von Request benötigt, damit die richtige SubCA die richtigen Zertifikate erzeugt.
[ RootCA ]

dir             = /usr/lib/ssl/RootCA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file
unique_subject  = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
email_in_dn     = yes
policy          = policy_match
x509_extensions = usr_cert              # The extentions to add to the cert
Diese Angaben sind die Grundeinstellungen für die verwendeten Verzeichnisse und Dateien.
Ich habe lieber jeden Key (den ich eh nur alle halbe jahr mal anschaue) mit ...CA.key.pem benannt.
Deswegen muß ich meine
certificate     = $dir/...CA.cert.pem
private_key     = $dir/private/...CA.key.pem
anpassen.
default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL
default_md      = md5                   # which md to use.
Die Standard-Gültigkeit von neu erstellten Zertifikaten soll ein Jahr (365 Tage) sein, CRLs sollen maximal 30 Tage gültig sein.

Folgende Policy soll gelten, wenn Requests signiert werden sollen. Dies ist je nach Zertifikatsgruppe unterschiedlich. Server-zertifikate müssen in viel mehr Punkten übereinstimmen als irgendwelche User irgendwo im Netz.
[ policy_match ]
countryName             = match
stateOrProvinceName     = optional
organizationName        = match   
organizationalUnitName  = supplied
commonName              = supplied
emailAddress            = optional
Hier wird angegeben, welche Felder eines Requests wie ausgefüllt sein müssen. match bedeutet, daß der Eintrag dem entsprechenden Eintrag der CA übereinstimmen muß, supplied bedeutet, daß dieses Feld angegeben sein muß, und optional ist wohl selbsterklärend. Wenn diese Felder nicht entsprechend ausgefüllt sind, kann ein Request nicht signiert werden.

In der Sektion
 [ req_distinguished_name ] 
werden die Benennungen und die Vorgabewerte für die einzelnen Felder eines Requests definiert.
hier stehen meine Eindeutschungen drin:
[ req_distinguished_name ]
countryName                     = Land (2stelliger Code)
countryName_default             = DE
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = Bundesstaat
#stateOrProvinceName_default    = Some-State

localityName                    = Stadt

0.organizationName              = Firma
#0.organizationName_default     = Internet Widgits Pty Ltd

# we can do this but it is not needed normally :-)
#1.organizationName             = Second Organization Name (eg, company)
#1.organizationName_default     = World Wide Web Pty Ltd

organizationalUnitName          = Abteilung
#organizationalUnitName_default =

commonName                      = Common Name
commonName_max                  = 64

emailAddress                    = eMail Adresse
emailAddress_max                = 64



Wichtig sind auch die x509v3 Erweiterungen. Hierdrin wird beschrieben, ob die Zertifikate, die durch die jeweilige CA ausgestellt werden, CA-Zertifikate oder nicht sind. Zertifikate, die an "EndUser" ausgestellt werden (als die Server-Zertifikate und die User-Zertifikate, DÜRFEN nicht das Attribut "basicConstraints = CA:true" haben. Dies ist ein bekannter Exploit in IE und fürt bei Netscape zu der Fehlermeldung 8183.

Es besteht schon dieser Abschnitt:
[ usr_cert ]
hinzugefügt habe ich noch die Parameter für CA-Zertifikate:
[ ca_cert ]
basicConstraints=CA:true
nsComment                       = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
Dieser Eintrag muss bei der RootCA im Feld
x509_extensions = ca_cert
angegeben werden. Die CAs, die Enduser-Zertifikate erstellen, brauchen die
x509_extensions = usr_cert





Anlegen der entsprechenden Verzeichnisse

In meinem Beispiel lege ich eine RootCA an, die die Zertifikate für eine ServerCA und eine UserCA signiert. Die ServerCA erstellt (signiert) zertifikate für den Gebrauch in Servern (die keine Passphrase haben) und die UserCA erstellt Zertifikate für User, die zur Authentisierung von Benutzern dienen. Diese drei CAs werden in eigenen Verzeichnissen geführt:
/usr/lib/ssl/
             RootCA
             ServerCA
             UserCA
Darunter brauchen wir jeweils folgende Unterverzeichnisse:
              ...CA/newcerts
              ...CA/certs
              ...CA/crl
              ...CA/private
und diese Dateien:
              ...CA/index.txt
              ...CA/serial
In die Datei serial wird 01 reingeschrieben
echo "01" > ...CA/serial
Bei Debian Linux sind schon einige Verzeichnisse angelegt, die allerdings nach /etc/ verlinkt sind. Diese sind zu löschen, damit wirklich alles unter /usr/lib/ssl liegt und man dort die Berechtigungen entsprechend sicher setzen kann.


Erzeugen der Zufallszahlen

Um einen guten Startwert der Zufallszahlen zu haben, wird die Datei .rand in jedem private Verzeichnis der einzelnen CAs angelegt. Dies geschieht am besten mit diesem Befehl:
for i in `find /usr/lib/ssl/ -name private`
   do cat /dev/urandom | 
      uuencode -m bla | 
      head -19 | 
      sed "s/begin.*//g" | 
      tail -18 | xargs | 
      sed "s/ //g" > $i/.rand
   chmod 770 $i/.rand
   ls -l  $i/.rand
done
Die obigen Zeilen kann man copy&pasten, allerdings muss das Programm uuencode und das Device /dev/urandom exisiteren. Unter Linux ist das meist vorhanden auf anderen unix-Systemen muss man sich mit /dev/random behelfen oder eine andere Datei benutzen.


Erzeugen des RootCA Zertifikats

Jetzt wird das (selbstsignierte) Zertifikat der RootCA erzeugt. Zuerst der Private Key, dieser muss unbedingt mit einer guten Passphrase geschützt werden, wenn man bedenkt, daß dieses Zertifikat die nächsten paar Jahre sicher sein soll.
openssl genrsa -aes256 -out /usr/lib/ssl/RootCA/private/RootCA.key.pem  \
                       -rand /usr/lib/ssl/RootCA/private/.rand 2048
Zu diesem privaten Schlüssel wird noch ein Öffentlicher Schlüssel (das Zertifikat) generiert. In meinem Fall soll das Zertifikat 5 Jahre (1827 Tage) gültig sein:
openssl req -new -x509 -days 1827 					\
                       -key /usr/lib/ssl/RootCA/private/RootCA.key.pem  \
                       -out /usr/lib/ssl/RootCA/RootCA.cert.pem
Dieses neue Zertifikat muss noch geprüft werden. Bei OpenSSL muss das Root-Zertifikat die Seriennummer 0 haben!
openssl x509 -in /usr/lib/ssl/RootCA/RootCA.cert.pem -text | less

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=DE, ST=Bayern, L=Neufahrn, O=Fra.nkSteidl.de, OU=Root CA, 
	CN=Fra.nkSteidl.de Root Certificate/emailAddress=RootCA@
fra.nksteidl.de
        Validity
            Not Before: Feb 20 17:16:48 2004 GMT
            Not After : Feb 20 17:16:48 2009 GMT
        Subject: C=DE, ST=Bayern, L=Neufahrn, O=Fra.nkSteidl.de, OU=Root CA, 
	CN=Fra.nkSteidl.de Root Certificate/emailAddress=RootCA
@fra.nksteidl.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:ce:b7:cb:41:40:27:3e:06:7f:78:08:3c:dc:08:
                    [...]
                    2d:11
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                5E:98:0C:1C:E9:59:15:3C:9F:1E:40:E5:91:A5:E4:73:60:46:BA:23
            X509v3 Authority Key Identifier: 
                keyid:5E:98:0C:1C:E9:59:15:3C:9F:1E:40:E5:91:A5:E4:73:60:46:BA:23
                DirName:/C=DE/ST=Bayern/L=Neufahrn/O=Fra.nkSteidl.de/OU=Root CA/
		CN=Fra.nkSteidl.de Root Certificate/emailAddress=RootCA@fra.nksteidl.de
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
        47:b0:55:e2:7f:9f:79:ef:3d:73:72:74:17:5a:33:b2:5e:63:
	[...]
        60:38:8e:bf
-----BEGIN CERTIFICATE-----
MIIE7TCCA9WgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBrzELMAkGA1UEBhMCREUx
[...]
apefY8oHn1NT9mSurGA4jr8=
-----END CERTIFICATE-----
Jetzt haben wir das Root-Zertifikat in der Datei /usr/lib/ssl/RootCA/RootCA.cert.pem und den zugehörigen Privaten Schlüssel in /usr/lib/ssl/RootCA/private/RootCA.key.pem.

Das Zertifikat muß jetzt noch an die Stelle kopiert werden, die in der Konfigurationsdatei openssl.cnf beschrieben ist:
	certificate     = $dir/cacert.pem
cp /usr/lib/ssl/RootCA/RootCA.cert.pem /usr/lib/ssl/RootCA/cacert.pem
genauso der Private Schlüssel:
	private_key     = $dir/private/cakey.pem
cp /usr/lib/ssl/RootCA/private/RootCA.key.pem /usr/lib/ssl/RootCA/private/cakey.pem
Um dieses erste Zertifikat der RootCA in das normale Handling der CA zu geben, muß es noch kopiert und verlinkt werden. Die Zertifikate werden im Unterverzeichnis certs mit dem Namen Ihrer Seriennummer gelegt und der Hash-Wert wird verlinkt:
	cd /usr/lib/ssl/RootCA
	cp RootCA.cert.pem /usr/lib/ssl/RootCA/certs/00.pem
	cd /usr/lib/ssl/RootCA/certs/
	ln -s 00.pem `openssl x509 -hash -noout -in 00.pem`.0 
Danach ist das erste Zertifikat erstellt und nach dem selben Prinzip werden die SubCA-Zertifikate erzeugt.


Erstellen der SubCAs

Zuerst wird wieder ein Privater Schlüssel für die SubCA erzeugt:
cd /usr/lib/ssl/ServerCA
openssl genrsa -aes256 -out /usr/lib/ssl/ServerCA/private/ServerCA.key.pem  \
                       -rand /usr/lib/ssl/ServerCA/private/.rand 2048
Daraus wird ein Zertifikats-Request generiert,
openssl req -new -key /usr/lib/ssl/ServerCA/private/ServerCA.key.pem  \
                 -out /usr/lib/ssl/ServerCA/ServerCA.req.pem
der dann von der RootCA signiert wird:
openssl ca -name RootCA -in /usr/lib/ssl/ServerCA/ServerCA.req.pem   \
                        -out /usr/lib/ssl/ServerCA/ServerCA.cert.pem
Dieses neue Zertifikat landet erstmal im Verzeichnis newcerts der RootCA (sie erstellt ja dieses Zertifikat). Von dort muß es in das Verzeichnis certs verschoben werden und sein Hash-Wert verlinkt werden:
mv /usr/lib/ssl/RootCA/newcerts/01.pem /usr/lib/ssl/RootCA/certs/
cd /usr/lib/ssl/RootCA/certs/
ln -s 01.pem `openssl x509 -in 01.pem -hash -noout`.0
Um dieses ServerCA Zertifikat in einen Browser zu integrieren, damit er allen von der ServerCA ausgestellten Zertifikaten vertraut, muß es noch umgewandelt werden. Dazu wird aus dem erzeugten Zertifikat der Teil zwischen
-----BEGIN CERTIFICATE-----
und
-----END CERTIFICATE-----
herauskopiert und in die Datei ServerCA.crt gespeichert. Diese Datei kann man online zur Verfügung stellen und in die Browser integrieren.
Auf dem selben Weg werden die anderen SubCA Zertifikate erzeugt:

1) Erstellen eines Private Keys in ...CA/private
2) Generieren eines Requests
3) Signieren des Requests durch die RootCA
4) kopieren des neuen zertifikats von newcerts nach certs
5) Verlinken des Hash-Wertes



Erstellen eines Server-Zertifikats

Mit der ServerCA lassen sich jetzt Zertifikate für Server erstellen. Diese sollten - weil sie ihren Private Key ohne menschliches Zutun benutzen müssen - keine Passphrase haben. Dies geschieht durch Weglassen des Verschlüsselungs-Algoritmus beim Erstellen des Private Key. Ansonsten sind das auch nur normale Zertifikate. Allerdings werden sie nicht von der RootCA, sondern von der ServerCA signiert.
cd ServerCA

openssl genrsa -out apache.key.pem -rand ./private/.rand 2048 

openssl req -new -key apache.key.pem -out apache.req.pem

openssl ca -name ServerCA -in apache.req.pem -out apache.cert.pem

mv newcerts/01.pem certs/
cd certs
ln -s 01.pem `openssl x509 -hash -noout -in 01.pem`.0
Auch hier muß das Zertifikat, sofern es in einen Browser integriert werden soll, in eine .crt Datei geschrieben werden (s.o.)


Erstellen eines User-Zertifikats

Im gegensatz zu Server-Zertifikaten sollten die Zertifikate der User durchaus eine Passphrase haben, die den Privaten Schlüssel vor unberechtigter Nutzung schützt.
cd UserCA

openssl genrsa -aes256 -out Frank.key.pem -rand ./private/.rand 1024 

openssl req -new -key Frank.key.pem -out Frank.req.pem

openssl ca -name UserCA -in Frank.req.pem -out Frank.cert.pem

mv newcerts/01.pem certs/
cd certs
ln -s 01.pem `openssl x509 -noout -hash -in 01.pem`.0
Die Datei *.key.pem enthält den privaten Schlüssel des Users. Dummerweise haben wir (als Admin) ihm gerade seine Passphrase gesetzt, was eigentlich nicht sein dürfte. Eigentlich sollte ein User sich diesen Privaten Schlüssel selber erzeugen, daraus den Request generieren und uns (dem Admin) zum Signieren geben.
Die Datei *.cert.pem enthält das Zertifikat, welches der User benutzt, um sich "auszuweisen" bzw. um Daten zu verschlüsseön. Je nach Anwendung kann es sein, daß dieses Zertifikat noch in PKCS#12 umgewandelt werden muß:
openssl pkcs12 -export -inkey Frank.key.pem 			\
		       -in Frank.cert.pem 			\
		       -name "Franks' 1024 Bit Zertifikat"	\
                       -out Frank.p12
Dabei kann noch ein Export Passwort gesetzt werden, welches beim Einfügen in den browser angegeben werden muß.


Widerrufen eines Zertifikats

Einmal ausgestellte Zertifikate werden nicht gelöscht. Wenn ein Zertifikat vor seinem Ablaufdatum ungültig werden soll, muß es widerrufen werden.
cd ...CA/
vi +/ index.txt
in der ersten Spalte aus einem V (valid) ein R (revoked) machen
in der dritten Spalte (nach dem Datum im YYMMDDHHMMSSZ Format) das Ablaufdatum im selben Format (UTC) eintragen


CRL erstellen

Die Information über ungültig gewordene Zertifikate (abgelaufen oder widerrufen) werden in einer CRL gepflegt. Pro (Sub)CA wird eine CRL erstellt:
openssl ca -name ...CA -gencrl -out /usr/lib/ssl/...CA/crl/crl.pem



Integration in Apache

Apache kann den Zugriff auf bestimmte Verzeichnisse nur ausgewählten Usern erlauben. Diese User können mit ihrem Zertifikat authentisiert werden. Dadurch erspart man dem User das Passwort-Popup und neben der Verschlüsselung wird auch eine Authentisierung mit der CA erreicht.

Für Apache gibt es zwei Möglichkeiten, SSL zu integrieren. Eine ist Apache-SSL, die andere ein normaler Apache mit mod_ssl integriert. Als ich mich zwischen beiden Varianten entscheiden mußte, machte mod_ssl einen einfacheren Eindruck und bot mir mehr Möglichkeiten. Meine Vorauswahl soll Euch allerdings nicht davon abhalten, die für Euch bessere Variante herauszufinden. Folgendes Beispiel ist allerdings auf mod_ssl gemünzt.

Zuerst muß das Modul installiert werden:
apt-get install libapache-mod-ssl
Danach muß das Modul in der Apache-Konfiguration auch geladen werden:
LoadModule ssl_module /usr/lib/apache/1.3/mod_ssl.so
Dann gibt es eine Reihe von Konfigurationen für dieses Modul. Hier die allgemeinen Informationen in der httpd.conf:
SSLCertificateFile      /etc/apache/Fra.nkSteidl.de.cert.pem                 
SSLCertificateKeyFile   /etc/apache/Fra.nkSteidl.de.key.pem

SSLCACertificateFile    /usr/lib/ssl/UserCA/UserCA.chain.cert.pem
SSLCARevocationFile     /usr/lib/ssl/UserCA/crl/crl.chain.pem

SSLLog                  /var/log/apache/ssl.log
SSLLogLevel             warn
SSLRandomSeed           startup /dev/urandom 2048
SSLRandomSeed           connect /dev/urandom 2048
SSLProtocol             all
SSLCipherSuite          ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLSessionCache         none
Die ersten beiden Einträge zeigen auf das (Server-)Zertifikat, welches für den Apache-Webserver erstellt wurde. Der Private Key hat sinnvollerweise keine Passphrase, sonst müßte man sie bei jedem Starten des Apache-Servers auf der Console eingeben.

Danach kommen zwei Einträge für die CA, die die User-Zertifikate unterschrieben hat. Von der User-CA brauchen wir das Zertifikat selber (nicht den Private Key, der geht den Apache gar nix an) als Zertifikats-Kette. D.h. alle Zertifikate, von der UserCA bis hin zur RootCA. Erstellt wird diese Datei einfach durch aneinanderhängen der einzelnen Zertifikats-Dateien:
cat ..../RootCA.cert.pem ..../UserCA.cert.pem > UserCA.chain.cert.pem
Die CRL, anhand der geprüft wird, ob ein spezielles User-Zertifikat schon abgelaufen oder zurückgezogen ist, wird nach dem selben Muster aus den einzelnen CRLs der übergeordneten CRLs zusammengebaut. Wenn sich irgendeine CRL der betiligten CAs ändert, sollte diese CRL wieder neu erstellt werden.

Die weiteren Optionen können in der Dokumentation zu mod_ssl auf der Seite www.modssl.org nachgelesen werden. Hier stehen auch weitere Parameter, die für Euch vielleicht interessant sein könnten.

Um spezielle Verzeichnisse nun verschlüsseln zu lassen, habe ich folgenden VirtualHost-Eintrg erstellt:
<VirtualHost 10.10.30.100:443>

Port 443
SSLEngine on
DocumentRoot /home/httpd/
ServerName Fra.nkSteidl.de
ServerAdmin webmaster@fra.nksteidl.de
ErrorLog /var/log/apache/error.log
CustomLog /var/log/apache/access.log combined

### This is not so secure, just encrypted, no UserCert needed:

<Directory /home/http>
  SSLRequireSSL       
  SSLVerifyClient none
  Options +FollowSymLinks +ExecCGI +Includes
  IndexOptions FancyIndexing
</Directory>
Dieser VirtualHost horcht auf Port 443, und benutzt SSL (SSLEngine on). Das Unterverzeichnis /home/httpd muß SSL-verschlüsselt werden (SSLRequireSSL), braucht aber kein Client-Zertifikat (SSLVerifyClient none).

Um ein Verzeichnis so zu schützen, daß der User ein gültiges Zertifikat besitzen muß, ist folgender Directory-Eintrag innerhalb des VirtualHost notwendig:
### This is more secure, you'll need a client certificate to authenticate

<Directory /home/httpd/secure>         
     SSLRequireSSL
     SSLVerifyClient     require
     SSLVerifyDepth      2
     SSLOptions          +ExportCertData +StrictRequire
     SSLRequire          (   %{SSL_CLIENT_S_DN_CN} == "Frank Steidl"    or  \
		             %{SSL_CLIENT_S_DN_CN} == "Markus May"       )  \  
                             and %{SSL_CLIENT_I_DN_CN} == "Fra.nkSteidl.de User CA Certificate"

     Options FollowSymLinks ExecCGI +Includes
     IndexOptions FancyIndexing          
</Directory>
</VirtualHost>
In dem Unterverzeichnis /secure muß auch wieder per SSL verschlüsselt werden (SSLRequireSSL), hier müssen jetzt auch die Client-Zertifikate geprüft werden (SSLVerifyClient require). Es wäre auch möglich, einen Client zu prüfen und notfalls auch ohne Zertifikat zugreifen zu lassen. Diese Optionen sind in der mod_ssl-Doku beschrieben.
SSLVerifyDepth 2 gibt an, das von einem Zertifikat zwei Instanzen "nach oben" geprüft werden, d.h. das Zertifikat selber, und das ausstellende Zertifikat (in unserem Fall die UserCA). Die SSLOptions +ExportCertData ist wichtig, um im nächsten Schritt die Parameter der User-Zertifikate auslesen und anhand derer Entscheidungen treffen zu können.
SSLRequire gibt die Bedingungen an, die erfüllt sein müssen, damit ein User mit seinem Zertifikat auf dieses Verzeichnis zugreifen darf. %{SSL_CLIENT_S_DN_CN} gibt den CN des Zertifikats-Inhabers an, %{SSL_CLIENT_I_DN_CN} gibt die CN des Issuers an. Beide bedingungen logisch mit AND und OR verknüpft sagt im obigen Beispiel:

Das User-Zertifikat muß auf den Namen Frank Steidl oder Markus May ausgestellt sein und von meiner UserCA ausgestellt (signiert) worden sein.

Genauere Verwendug all der Variablen, die man hier zur Verfügung hat, finden sich in der mod_ssl-Dokumenation.






© by Frank Steidl • eMail: Fr @nkSteidl.de • Homepage: Fra .nkSteidl.de