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.

So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten

In diesem Verfahren erstellen Sie ein Zertifikatpaar. Der private Schlüssel wird auf einer Festplatte in der lokalen Zertifikatdatenbank gespeichert und kann über den Unterbefehl certlocal referenziert werden. Der öffentliche Teil des Zertifikatpaars wird in der öffentlichen Zertifikatdatenbank gespeichert. Dieser kann über den Unterbefehl certdb referenziert werden. Ersetzen Sie den öffentlichen Teil durch ein Peer-System. Die Kombination der beiden Zertifikate wird zur Authentifizierung der IKE-Übertragungen verwendet.

Selbst-designierte Zertifikate erfordern weniger Aufwand als öffentliche Zertifikate von einer CA, lassen sich jedoch nicht einfach skalieren. Im Gegensatz zu Zertifikaten, die von einer CA ausgegeben werden, müssen selbstsignierte Zertifikate außerbandig verifiziert werden.

Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.
Die Rolle "Primary Administrator" enthält das gleichnamige 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 Oracle Solaris Administration: 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.
Erstellen Sie ein selbst-signiertes Zertifikat in der Datenbank ike.privatekeys.
```
# 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-sha1 \
-D "C=US, O=PartyCo, 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-----
```
  Hinweis - Die Werte der Optionen -D und -A sind beliebig wählbar. Mit den Werten wird nur das Zertifikat identifiziert. Sie werden nicht zur Identifikation eines Systems verwendet, Beispiel: 192.168.13.213. Da diese Werte spezifisch sind, müssen Sie außerbandig verifizieren, dass auf den Peer-Systemen das korrekte Zertifikat installiert ist.
2. Der Befehl auf dem System enigma sieht in etwa wie folgt aus:
```
# ikecert certlocal -ks -m 1024 -t rsa-sha1 \
-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.
Die Ausgabe ist eine verschlüsselte Version des öffentlichen Teils des Zertifikats. Sie können dieses Zertifikat sicher in eine E-Mail einfügen. Der Empfänger muss außerbandig verifizieren, dass er das korrekte Zertifikat installiert hat. Anweisungen hierzu finden Sie in Schritt 5.
1. Beispiel: Senden Sie den öffentlichen Teil des folgenden partym-Zertifikats an den enigma-Administrator:
```
To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----
```
2. Der enigma-Administrator sendet Ihnen dann den öffentlichen Teil des folgenden enigma-Zertifikats:
```
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.
Beispiel: Sie können den anderen Administrator anrufen, um zu überprüfen, dass der Hash-Wert dessen öffentlichen Zertifikats, welches Sie haben, mit dem Hash-Wert dessen privaten Zertifikats, das nur er hat, übereinstimmt.
1. Listet das auf partym gespeicherte Zertifikat auf.
  Im folgenden Beispiel gibt Hinweis 1 den Distinguished Name (DN) des Zertifikats in Slot 0 an. Das private Zertifikat in Slot 0 hat denselben Hash-Wert (siehe Hinweis 3); diese Zertifikate stellen also dasselbe Zertifikatpaar dar. Die öffentlichen Zertifikate funktionieren nur, wenn Sie ein übereinstimmendes Paar besitzen. Der Unterbefehl certdb listet den öffentlichen Teil auf, während der Unterbefehl certlocal den privaten Teil angibt.
```
partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-sha1 
    Subject Name: <C=US, O=PartyCo, OU=US-Partym, CN=Partym>Note 1
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

Certificate Slot Name: 1   Type: rsa-sha1 
    (Private key in certlocal slot 0)
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2
partym # ikecert certlocal -l
Local ID Slot Name: 0   Key Type: rsa-sha1
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818Note 3

Local ID Slot Name: 1   Key Type: rsa-sha1
        Key Size: 1024
        Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
...
```
  In dieser Prüfung wurde verifiziert, dass das System partym über ein gültiges Zertifikatpaar verfügt.
2. Überprüfen Sie, ob das System enigma das öffentliche Zertifikat von partym besitzt.
  Sie können den PublicKey-Hash über das Telefon vorlesen.
  Vergleichen Sie die Hash-Werte aus Hinweis 3 auf partym im vorherigen Schritt mit Hinweis 4 auf enigma.
```
enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-sha1 
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-sha1 
    Subject Name: <C=US, O=PartyCo, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818Note 4
```
  Der PublicKey-Hash und der Themenname des zuletzt in der öffentlichen Zertifikatdatenbank von enigma gespeicherten Zertifikats stimmen mit dem privaten Zertifikat für partym aus dem vorangegangenen Schritt überein.

Richten Sie auf den Systemen eine Vertrauensstellung für 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 self-signed certs
# that we verified out of band. The local certificate
# is implicitly trusted because we have access to the private key.
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 3des }
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

# We could explicitly enter the peerâs IP address here, but we donât need
# to do this with certificates, so use a wildcard address. The wildcard
# allows the remote device to be mobile or behind a NAT box.
# remote_addr 192.168.116.16
 remote_addr 0.0.0.0/0

 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. Stellen Sie sicher, dass der Wert für das Schlüsselwort label auf dem lokalen System eindeutig ist.
```
…
{
 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 0.0.0.0/0
…
```

Beispiel 23-4 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-sha1 \
-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-sha1 \
-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 "Primary Administrator" enthält das gleichnamige 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 Oracle Solaris Administration: 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-sha1 \
> -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-sha1 \
> -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 3des }
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-5 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 in 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 "Primary Administrator" enthält das gleichnamige 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 Oracle Solaris Administration: 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 - Die Sun Crypto Accelerator 4000 und Sun Crypto Accelerator 6000 Boards unterstützen Schlüssel bis zu 2048 Bit für RSA. Für DSA unterstützen sie Schlüssel bis zu 1024 Bit.
- Bei einem selbst-signiertem Zertifikate verwenden Sie die folgende Syntax.
```
# ikecert certlocal -ks -m 1024 -t rsa-sha1 \
> -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 Boards.
- Bei einer Zertifikat-Anforderung verwenden Sie die folgende Syntax.
```
# ikecert certlocal -kc -m 1024 -t rsa-sha1 \
> -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 Board-Benutzer, einen Doppelpunkt und das Passwort des Benutzers ein.
Hat das 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, so dass 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}
}

Zertifikatanforderung

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-6.

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 Verbose-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 Oracle herausgegeben. Bestimmte Einzelheiten wurden geändert.

# ikecert certdb -lv example-protect.oracle.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Oracle, CN=example-protect.oracle.com>
 Issuer Name: <CN=Oracle CA (Cl B), O=Oracle>
 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.oracle.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.oracle.com/pki/pkismica.crl#i
         DN = <CN= Oracle CA (Cl B), O=Oracle>
      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.oracle.com:389,ldap2.oracle.com"
…
```
IKE ruft die CRL ab und speichert die CRL zwischen, bis das Zertifikat abgelaufen ist.

Beispiel 23-6 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 < Oracle.Cert.CRL

Navigationslinks überspringen
Druckansicht beenden
	Oracle Systemverwaltungshandbuch: IP-Services Oracle Solaris 10 1/13 Information Library (Deutsch)