Konfiguration von IKE mit PublicKey-Zertifikaten

Mit PublicKey-Zertifikaten müssen kommunizierende Systeme kein geheimes außerbandiges Schlüsselmaterial mehr verwenden. Im Gegensatz zu PresharedKeys kann ein PublicKey-Zertifikat auf einem mobilen Computer oder auf einem System verwendet werden, dass neu nummeriert werden kann.

PublicKey-Zertifikate können auch auf angehängter Hardware gespeichert werden. Informationen hierzu finden Sie unter Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte).

So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten

Selbst-designierte Zertifikate erfordern weniger Aufwand als öffentliche Zertifikate von einer CA, lassen sich jedoch nicht einfach skalieren.

Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.
Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

Hinweis - Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.
Fügen Sie ein selbst-signiertes Zertifikat in die Datenbank ike.privatekeys ein.
```
# ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]
```
-ks

Erstellt ein selbst-signiertes Zertifikat.

-kc

Erstellt eine Zertifikatanforderung. Informationen hierzu finden Sie unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

-m Schlüsselgröße

Die Größe des Schlüssels. Schlüsselgröße kann 512, 1024, 2048, 3072 oder 4096 annehmen.

-t Schlüsseltyp

Gibt den zu verwendenden Algorithmustyp an. Schlüsseltyp kann rsa-sha1, rsa-md5 oder dsa-sha1 annehmen.

-D dname

Der X.509-Distinguished Name (DN) für das Zertifikatssubjekt. dname hat in der Regel folgende Form: C=Land, O= Organisation, OU= Organisationseinheit, CN= allgemeiner Name. Gültige Tags sind C, O, OU und CN.

-A altname

Der Alternativname für das Zertifikat. altname hat im allgemeinen das Format Tag=Wert. Gültige Tags sind IP, DNS, email und DN.

-S Gültigkeit-Anfang

Ist das absolute oder relative Anfangsdatum der Zertifikatsgültigkeit.

-F Gültigkeit-Ende

Ist das absolute oder relative Enddatum der Zertifikatsgültigkeit.

-T Token-ID

Ermöglicht, dass ein PKCS&;#11-Hardwaretoken die Schlüssel erzeugt. Die Zertifikate werden dann auf der Hardware gespeichert.
1. Der Befehl auf dem System partym sieht in etwa wie folgt aus:
```
# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----
```
2. Der Befehl auf dem System enigma sieht in etwa wie folgt aus:
```
# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----
```

Speichern Sie das Zertifikat und senden Sie es an das remote System.

Sie können das Zertifikat in eine E-Mail einfügen.

So können Sie das folgende partym-Zertifikat an den Administrator von enigma senden:

To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

Der Administrator von enigma sendet Ihnen das folgende enigma-Zertifikat:

To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

</remark>Fügen Sie auf jedem System das empfangene Zertifikat ein.
1. Kopieren Sie den PublicKey aus der E-Mail des Administrators.
2. Geben Sie den Befehl ikecert certdb -a ein, und drücken Sie die Eingabetaste.
  Wenn Sie die Eingabetaste drücken, werden keine Eingabeaufforderungen angezeigt.
```
# ikecert certdb -a Press the Return key
```
3. Fügen Sie den PublicKey ein, und drücken Sie die Eingabetaste. Drücken Sie dann Strg-D, um den Eintrag zu beenden.
```
-----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key
<Control>-D
```

Prüfen Sie gemeinsam mit dem anderen Administrator, dass das Zertifikat von diesem Administrator stammt.

Beispielsweise können Sie mit dem anderen Administrator telefonieren und die Werte des PublicKey-Hash vergleichen. Das PublicKey-Hash für das gemeinsam genutzte Zertifikat muss auf beiden Systemen gleich sein.

Listen Sie das gespeicherte Zertifikat auf Ihrem System auf.

So befindet sich das öffentliche Zertifikat z. B. auf dem System partym in Slot 1 und das private Zertifikat in Slot 0.

partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

Vergleichen Sie diesen Wert mit dem PublicKey-Hash auf dem System enigma.

Sie können den PublicKey-Hash über das Telefon vorlesen.

enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

Richten Sie auf den Systemen eine Vertrauensstellung für die beide Zertifikate ein.

Ändern Sie die Datei /etc/inet/ike/config so, dass die Zertifikate erkannt werden.

Der Administrator des remoten Systems stellt die Werte für die Parameter cert_trust, remote_addr und remote_id zur Verfügung.

Auf dem System partym enthält die ike/config-Datei Folgendes:

# Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## Parameters that may also show up in rules.

p1_xform 
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 5

{
 label "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

Geben Sie auf dem System enigma die enigma-Werte für lokale Parameter in die Datei ike/config ein.
Für die remoten Parameter verwenden Sie partym-Werte. Achten Sie darauf, dass der Wert für das Schlüsselwort label einmalig ist. Der Wert muss sich von dem label-Wert des remoten Systems unterscheiden.
```
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…
```

Beispiel 23-4 Prüfen Sie, ob das Zertifikat vom anderen Administrator gültig ist

In diesem Beispiel verwenden die Administratoren den „Subject Name“ um sicherzustellen, dass die Zertifikate identisch sind.

Der erste Administrator speichert die Ausgabe des Erzeugens und Auflistens des Zertifikats in einer Datei. Da die Ausgabe des ikecert-Befehls in den Standardfehler druckt, leitet der Administrator den Standardfehler an die Datei um.

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

Der Administrator überprüft den Inhalt der Datei.

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Dann sendet der Administrator die Datei in einer E-Mail an den zweiten Administrator.

Der zweite Administrator fügt die Datei in ein sicheres Verzeichnis ein und importiert dann das Zertifikat aus der Datei.

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

Der Befehl ikecert importiert nur den Text zwischen den Zeilen -----BEGIN und -----END. Der Administrator überprüft, ob das lokale Zertifikat den gleichen öffentlichen Key-Hash wie in der Datei co2sys aufweist.

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Um sicherzustellen, dass der erste Administrator diese E-Mail gesendet hat, telefoniert der zweite Administrator, um die Richtigkeit des „Subject Name“ des Zertifikats zu bestätigen.

Beispiel 23-5 Einrichten von Anfangs- und Enddatum für die Gültigkeit eines Zertifikats

In diesem Beispiel gibt der Administrator des Systems partym vor, wie lange ein Zertifikat gültig ist. Das Zertifikat ist um 2 1/2 Tage zurückdatiert und gilt für vier Jahre und sechs Monate ab dem Erstellungsdatum.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

Der Administrator des Systems enigma gibt die Daten an, innerhalb denen das Zertifikat gültig ist. Das Zertifikat wurde um zwei Tage zurückdatiert und gilt bis Mitternacht am 31. Dezember 2010.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden

Öffentliche Zertifikate einer Zertifikatsautorität (CA) machen eine Aushandlung mit einer außenstehenden Organisation erforderlich. Diese Zertifikate können leicht skaliert werden, sodass zahlreiche miteinander kommunizierende Systeme geschützt werden können.

Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.
Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

Hinweis - Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

Geben Sie den Befehl ikecert certlocal -kc ein, um ein Zertifikat anzufordern.

Eine Beschreibung der Argumente dieses Befehls finden Sie in Schritt 2 unter So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten.

# ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

Der folgende Befehl erstellt eine Zertifikat-Anforderung auf dem System partym:

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

Der folgende Befehl erstellt eine Zertifikat-Anforderung auf dem System enigma:

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

Übermitteln Sie die Zertifikat-Anforderung an eine PKI-Organisation.
Die PKI-Organisation teilt Ihnen mit, wie die Zertifikat-Anforderung übermittelt werden soll. Die meisten Organisationen verfügen über eine Website mit einem Übertragungsformular. Das Formular fordert einen Beweis, dass die Übertragung legitim ist. In der Regel fügen Sie Ihre Zertifikat-Anforderung in das Formular ein. Nachdem Ihre Anforderung von der Organisation überprüft wurde, stellt sie die folgenden zwei Zertifikatsobjekte sowie eine Liste zurückgenommenen Zertifikate aus:
- Ihr PublicKey-Zertifikat – Dieses Zertifikat basiert auf der Anforderung, die Sie an die Organisation übermittelt haben. Die von Ihnen übermittelte Anforderung ist Teil dieses PublicKey-Zertifikats. Das Zertifikat identifiziert Sie eindeutig.
- Eine Zertifikatsautorität – Die Signatur der Organisation. Die CA prüft, ob Ihr PublicKey-Zertifikat echt und unverfälscht ist.
- Eine Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) – Die aktuelle Liste der Zertifikate, die von der Organisation zurückgenommen wurden. Die CRL wird nicht separat als ein Zertifikatsobjekt gesendet, wenn der Zugriff auf die CRL in das PublicKey-Zertifikat eingebettet ist.
  
  Ist ein URI für die CRL in das PublicKey-Zertifikat eingebettet, kann IKE die CRL automatisch für Sie abrufen. Entsprechend gilt, ist ein DN-Eintrag (Verzeichnisname auf einem LDAP-Server) in das PublicKey-Zertifikat eingebettet, kann IKE die CRL vom angegebenen LDAP-Server abrufen und zwischenspeichern.
  
  Ein Beispiel eines eingebetteten URI und eines eingebetteten DN-Eintrags in einem PublicKey-Zertifikat finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.
Fügen Sie Ihrem System alle Zertifikate hinzu.
Mit der Option -a des Befehls ikecert certdb -a fügen Sie das eingefügte Objekt der entsprechenden Zertifikatdatenbank Ihres Systems hinzu. Weitere Informationen finden Sie unter IKE mit PublicKey-Zertifikaten.
1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.
2. Fügen Sie das PublicKey-Zertifikat hinzu, das Sie von der PKI -Organisation empfangen haben.
```
# ikecert certdb -a
Press the Return key
Paste the certificate:
-----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE----
Press the Return key
<Control>-D
```
3. Fügen Sie die CA von der PKI-Organisation hinzu.
```
# ikecert certdb -a
Press the Return key
Paste the CA:
-----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE----
Press the Return key
<Control>-D
```
4. Wenn die PKI-Organisation eine Liste der zurückgenommenen Zertifikate gesendet hat, fügen Sie die CRL zur certrldb-Datenbank hinzu:
```
# ikecert certrldb -a
Press the Return key
Paste the CRL:
-----BEGIN CRL----- … -----END CRL----
Press the Return key
<Control>-D
```

Geben Sie das Schlüsselwort cert_root ein, um die PKI-Organisation in der Datei /etc/inet/ike/config zu identifizieren.

Verwenden Sie den von der PKI-Organisation angegebenen Namen.

Die Datei ike/config auf dem System partym könnte wie folgt aussehen:

# Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform 
 { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "US-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

Hinweis - Alle Argumente für den Parameter auth_method müssen sich auf der gleichen Zeile befinden.

Erstellen Sie eine ähnliche Datei auf dem System enigma.
Beachten Sie bei der Datei enigma ike/config Folgendes:
- Fügen Sie den gleichen cert_root-Wert hinzu.
- Verwenden Sie enigma-Werte für lokale Parameter.
- Verwenden Sie partym-Werte für remote Parameter.
- Erstellen Sie einen einmaligen Wert für das Schlüsselwort label. Der Wert muss sich von dem label-Wert des remoten Systems unterscheiden.
```
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…
```

Weisen Sie IKE an, wie die CRLs verarbeitet werden sollen.
Wählen Sie die geeignete Option:
- Keine CRL verfügbar
  Wenn die PKI-Organisation keine CRL zur Verfügung stellt, fügen Sie das Schlüsselwort ignore_crls zur ike/config -Datei hinzu.
```
# Trusted root cert
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,…
ignore_crls
…
```
  Das Schlüsselwort ignore_crls weist IKE an, nicht nach CRLs zu suchen.
- CRL verfügbar
  Wenn die PKI-Organisation einen zentralen Verteilungspunkt für CRLs bereitstellt, können Sie in der Datei ike/config auf diesen Speicherort verweisen.
  Beispiele finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

Beispiel 23-6 Verwenden von rsa_encrypt bei der Konfiguration von IKE

Wenn Sie auth_method rsa_encrypt in der ike/config-Datei angeben, müssen Sie das Zertifikat des Peers zur publickeys-Datenbank hinzufügen.

Senden Sie das Zertifikat an den Administrator des remoten Systems.

Sie können das Zertifikat in eine E-Mail einfügen.

Der Administrator von partym sendet Ihnen die folgende E-Mail:

To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII…
----END X509 CERTIFICATE-----

Der Administrator von enigma sendet die folgende E-Mail:

To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII
…
-----END X509 CERTIFICATE-----

Fügen Sie das per E-Mail gesendete Zertifikat auf beiden Systemen zur lokalen publickeys-Datenbank hinzu.

# ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

Die Authentifizierungsmethode für die RSA-Verschlüsselung verbirgt Identitäten in IKE vor möglichen Lauschangriffen. Da die rsa_encrypt-Methode die Identität des Peers verbirgt, kann IKE das Zertifikat des Peers nicht abrufen. Aus diesem Grund erfordert die rsa_encrypt-Methode, dass die IKE-Peers die PublicKeys des jeweils anderen Systems kennen.

Wenn Sie den auth_method rsa_encrypt in der /etc/inet/ike/config-Datei angeben, müssen Sie das Zertifikat des Peers zur publickeys-Datenbank hinzufügen. Die publickeys-Datenbank enthält dann drei Zertifikate für jedes kommunizierenden Systempaar:

Ihr PublicKey-Zertifikat
Das CA-Zertifikat
Das PublicKey-Zertifikat des Peer

Fehlerbehebung – Die IKE-Nutzlast, zu der auch die drei Zertifikate gehören, könnte zu groß werden, sodass eine Verschlüsselung durch rsa_encrypt nicht mehr möglich ist. Fehlermeldungen wie „Autorisierung fehlgeschlagen“ und „Fehlerhafte Nutzlast“ deuten darauf hin, dass die rsa_encrypt-Methode nicht die gesamte Nutzlast verschlüsseln konnte. Reduzieren Sie die Nutzlastgröße mit einer Methode wie z. B. rsa_sig, die nur zwei Zertifikate erfordert.

So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware

Das Erzeugen von PublicKey-Zertifikaten und das Speichern dieser Zertifikate auf angehängter Hardware ähnelt dem Erzeugen von PublicKey-Zertifikaten und dem Speichern dieser Zertifikate auf Ihrem System. Auf der Hardware müssen die Befehle ikecert certlocal und ikecert certdb die Hardware identifizieren. Die Option -T mit der Token-ID identifiziert die Hardware gegenüber den Befehlen.

Bevor Sie beginnen

Die Hardware muss konfiguriert sein.
Die Hardware verwendet die /usr/lib/libpkcs11.so-Bibliothek, es sei denn, das Schlüsselwort pkcs11_path in der /etc/inet/ike/config-Datei verweist auf eine andere Bibliothek. Die Bibliothek muss gemäß dem folgenden Standard implementiert sein: RSA Security Inc. PKCS&;#11 Cryptographic Token Interface (Cryptoki), das heißt, eine PKCS&;#11-Bibliothek.

Informationen zum Setup finden Sie unter So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board.

Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.
Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

Hinweis - Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.
Erzeugen Sie ein selbst-signiertes Zertifikat oder eine Zertifikat-Anforderung, und geben Sie die Token-ID an.
Wählen Sie eine der folgenden Optionen:

Hinweis - Für RSA unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu 2048 Bit. Für DSA unterstützt dieses Board Schlüssel bis zu 1024 Bit.
- Bei einem selbst-signiertem Zertifikate verwenden Sie die folgende Syntax.
```
# ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password
```
  Das Argument für die Option -T ist die Token-ID des angehängten Sun Crypto Accelerator 4000-Boards.
- Bei einer Zertifikat-Anforderung verwenden Sie die folgende Syntax.
```
# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password
```
Eine Beschreibung der Argumente für den Befehl ikecert finden Sie in der Manpage ikecert(1M).
Geben Sie an der Eingabeaufforderung für eine PIN den Sun Crypto Accelerator 4000-Benutzer, einen Doppelpunkt und das Passwort des Benutzers ein.
Hat das Sun Crypto Accelerator 4000-Board beispielsweise den Benutzer ikemgr, dessen Passwort rgm4tigt lautet, geben Sie Folgendes ein:
```
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
```
Hinweis - Die PIN-Antwort wird auf dem Datenträger als Reintext gespeichert.

Nachdem Sie das Passwort eingegeben haben, druckt das Zertifikat Folgendes:
```
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----
```
Senden Sie Ihr Zertifikat an die andere Partei.
Wählen Sie eine der folgenden Optionen:
- Senden Sie das selbst-signierte Zertifikat an das remote System.
  Sie können das Zertifikat in eine E-Mail einfügen.
- Senden Sie die Zertifikat-Anforderung an eine Organisation, die PKI verarbeitet.
  Folgen Sie den Anweisungen der PKI-Organisation zur Übermittlung der Zertifikat-Anforderung. Ausführliche Anweisungen finden Sie in Schritt 3 unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

Ändern Sie auf Ihrem System die Datei /etc/inet/ike/config, sodass die Zertifikate erkannt werden.

Wählen Sie eine der folgenden Optionen.

Selbst-signiertes Zertifikat

Verwenden Sie die vom Administrator des remoten Systems bereitgestellten Werte für die Parameter cert_trust, remote_id und remote_addr. Auf dem System enigma enthält die ike/config-Datei Folgendes:

# Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name


# Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path
"/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

Zertifikat-Anforderung

Geben Sie den von der PKI-Organisation bereitgestellten Namen als Wert für das Schlüsselwort cert_root ein. Die Datei ike/config könnte auf dem System enigma wie folgt aussehen:

# Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

# Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path
"/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

Speichern Sie die Zertifikate der anderen Partei auf der angehängten Hardware.
Antworten Sie auf die PIN-Anforderung, wie Sie in Schritt 3 geantwortet haben.

Hinweis - Sie müssen die PublicKey-Zertifikate auf der angehängten Hardware speichern, die Ihren PrivateKey erstellt hat.
- Selbst-signiertes Zertifikat.
  Fügen Sie das selbst-signierte Zertifikat des remoten Systems hinzu. In diesem Beispiel wird das Zertifikat in der Datei DCA.ACCEL.STOR.CERT gespeichert.
```
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password
```
  Wenn das selbst-signierte Zertifikat rsa_encrypt als Wert für den Parameter auth_method verwendet, fügen Sie das Zertifikat des Peers zum Hardwarespeicher hinzu.
- Zertifikate von einer PKI-Organisation.
  Fügen Sie die von der Organisation als Antwort auf Ihre Zertifikate-Anforderung erzeugten Zertifikate und die Zertifikatsautorität (CA) hinzu.
```
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password
```
```
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT
Enter PIN for PKCS#11 token: Type user:password
```
  Informationen zum Hinzufügen der Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) von der PKI-Organisation finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

So verarbeiten Sie eine Zertifikat-Rücknahmeliste

Eine Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) enthält veraltete und sicherheitsgefährdete Zertifikate einer Zertifikatsautorität. Es gibt vier Möglichkeiten, CRLs zu verarbeiten.

Sie müssen IKE anweisen, CRLs zu ignorieren, wenn Ihre CA-Organisation keine CRLs ausgibt. Diese Option wird in Schritt 6 unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden dargestellt.
Sie können IKE anweisen, über einen URI (Uniform Resource Indicator), dessen Adresse in das PublicKey-Zertifikat von der CA eingebettet ist, auf die CRLs zugreifen.
Sie können IKE anweisen, über einen LDAP-Server, dessen DN-Eintrag (Verzeichnisname) in das PublicKey-Zertifikat von der CA eingebettet ist, auf die CRLs zugreifen.
Sie können die CRL als ein Argument für den Befehl ikecert certrldb angeben. Ein Beispiel finden Sie unter Beispiel 23-7.

Im folgenden Verfahren wird beschrieben, wie Sie IKE anweisen, CRLs von einem zentralen Verteilungspunkt aus zu verwenden.

Zeigen Sie die von der CA empfangenen Zertifikate an.

# ikecert certdb -lv certspec

-l: Listet die Zertifikate in der IKE-Zertifikatsdatenbank auf.
-v: Listet die Zertifikate im ausführlichen Modus auf. Verwenden Sie diese Option nur nach sorgfältigen Überlegungen.
certspec: Ein Muster, das Entsprechungen für ein Zertifikat in der IKE-Zertifikatsdatenbank findet.

Das folgende Zertifikat wurde beispielsweise von Sun Microsystems herausgegeben. Bestimmte Einzelheiten wurden geändert.

# ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A…A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

Beachten Sie den Eintrag CRL Distribution Points. Der URI-Eintrag kennzeichnet, dass die CRL dieser Organisation im Web verfügbar ist. Der DN-Eintrag gibt an, dass die CRL auf einem LDAP-Server zur Verfügung steht. Nachdem IKE einmal auf die CRL zugegriffen hat, wird sie zur weiteren Verwendung zwischengespeichert.

Um auf die CRL zuzugreifen, müssen Sie einen Verteilungspunkt erreichen.

Wählen Sie eine der folgenden Methoden, um auf die CRL an einem zentralen Verteilungspunkt zuzugreifen.
- Mithilfe des URI.
  Fügen Sie das Schlüsselwort use_http zur Datei /etc/inet/ike/config des Hosts hinzu. Die Datei ike/config ähnelt dann Folgendem:
```
# Use CRL from organization's URI
use_http
…
```
- Mithilfe eines Web-Proxy.
  Fügen Sie das Schlüsselwort proxy zur ike/config-Datei hinzu. Das Schlüsselwort proxy akzeptiert eine URL als Argument, wie in dem folgenden Beispiel:
```
# Use own web proxy
proxy "http://proxy1:8080"
```
- Mithilfe eines LDAP-Servers.
  Geben Sie den LDAP-Server als Argument für das Schlüsselwort ldap-list in die /etc/inet/ike/config-Datei des Hosts ein. Ihre Organisation stellt den Namen des LDAP-Servers zur Verfügung. Der Eintrag in der ike/config-Datei würde Folgendem ähneln:
```
# Use CRL from organization's LDAP
ldap-list "ldap1.sun.com:389,ldap2.sun.com"
…
```
IKE ruft die CRL ab und speichert die CRL zwischen, bis das Zertifikat abgelaufen ist.

Beispiel 23-7 Einfügen einer CRL in die lokale certrldb-Datenbank

Wenn die CRL einer PKI-Organisation nicht an einem zentralen Verteilungspunkt zur Verfügung steht, können Sie die CRL der zur lokalen certrldb-Datenbank manuell hinzufügen. Folgen Sie den Anweisungen der PKI-Organisation zum Extrahieren der CRL in eine Datei, dann fügen Sie die CRL mit dem Befehl ikecert certrldb -a zur Datenbank hinzu.

# ikecert certrldb -a < Sun.Cert.CRL

Navigationslinks �berspringen
Druckansicht beenden
	Systemverwaltungshandbuch: IP Services