| Skip Navigation Links | |
| Exit Print View | |
|
Securing the Network in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Securing the Network in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. Using Link Protection in Virtualized Environments
2. Tuning Your Network (Tasks)
3. Web Servers and the Secure Sockets Layer Protocol
4. IP Filter in Oracle Solaris (Overview)
6. IP Security Architecture (Overview)
8. IP Security Architecture (Reference)
9. Internet Key Exchange (Overview)
How to Display Available Groups and Algorithms for Phase 1 IKE Exchanges
Configuring IKE With Preshared Keys (Task Map)
Configuring IKE With Preshared Keys
How to Configure IKE With Preshared Keys
How to Update IKE for a New Peer System
Configuring IKE With Public Key Certificates (Task Map)
Configuring IKE With Public Key Certificates
How to Configure IKE With Self-Signed Public Key Certificates
How to Configure IKE With Certificates Signed by a CA
How to Generate and Store Public Key Certificates in Hardware
Configuring IKE for Mobile Systems (Task Map)
Configuring IKE for Mobile Systems
How to Configure IKE for Off-Site Systems
Configuring IKE to Find Attached Hardware
How to Configure IKE to Find the Sun Crypto Accelerator 6000 Board
Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Unlike preshared keys, a public key certificate can be used on a mobile machine or on a system that might be renumbered.
Public key certificates can also be generated and stored in attached hardware. For the procedure, see Configuring IKE to Find Attached Hardware.
In this procedure, you create a certificate pair. The private key is stored on disk in the local certificate database and can be referenced by using the certlocal subcommand. The public portion of the certificate pair is stored in the public certificate database. It can be referenced by using the certdb subcommand. You exchange the public portion with a peer system. The combination of the two certificates is used to authenticate the IKE transmissions.
Self-signed certificates require less overhead than public certificates from a CA, but do not scale very easily. Unlike certificates that are issued by a CA, self-signed certificates must be verified out of band.
Before You Begin
You must become an administrator who is assigned the Network IPsec Management rights profile, in addition to the solaris.admin.edit/etc/inet/ike/config authorization. The root role has all of these rights. For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
If you log in remotely, use the ssh command for a secure remote login. For an example, see Example 7-1.
# ikecert certlocal -ks -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID]
Creates a self-signed certificate.
Is the size of the key. The keysize can be 512, 1024, 2048, 3072, or 4096.
Specifies the type of algorithm to use. The keytype can be rsa-sha1, rsa-md5, or dsa-sha1.
Is the X.509 distinguished name for the certificate subject. The dname typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.
Is the alternate name for the certificate. The altname is in the form of tag=value. Valid tags are IP, DNS, email, and DN.
Provides an absolute or relative valid start time for the certificate.
Provides an absolute or relative valid end time for the certificate.
Enables a PKCS #11 hardware token to generate the keys. The certificates are then stored in the hardware.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ -D "O=exampleco, OU=IT, C=US, CN=partym" \ -A IP=192.168.13.213 Creating private key. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T a...+ zBGi4QkNdI3f -----END X509 CERTIFICATE-----
Note - The values of the -D and -A options are arbitrary. The values are used to identify the certificate only. They are not used to identify a system, such as 192.168.13.213. In fact, because these values are idiosyncratic, you must verify out of band that the correct certificate is installed on the peer systems.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ -D "O=exampleco, OU=IT, C=US, CN=enigma" \ -A IP=192.168.116.16 Creating private key. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T ... y85m6LHJYtC6 -----END X509 CERTIFICATE-----
The output is an encoded version of the public portion of the certificate. You can safely paste this certificate into an email. The receiving party must verify out of band that they installed the correct certificate, as shown in Step 4.
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T a...+ zBGi4QkNdI3f -----END X509 CERTIFICATE------
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: ----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T ... y85m6LHJYtC6 -----END X509 CERTIFICATE-----
# ikecert certdb -a < /tmp/certificate.eml
The command imports the text between the BEGIN and END tags.
For example, you can telephone the other administrator to verify that the hash of their public certificate, which you have, matches the hash of their private certificate, which only they have.
In the following example, Note 1 indicates the distinguished name (DN) of the certificate in slot 0. The private certificate in slot 0 has the same hash (see Note 3), so these certificates are the same certificate pair. For the public certificates to work, you must have a matching pair. The certdb subcommand lists the public portion, while the certlocal subcommand lists the private portion.
partym # ikecert certdb -l
Certificate Slot Name: 0 Key Type: rsa
(Private key in certlocal slot 0)
Subject Name: <O=exampleco, OU=IT, C=US, CN=partym>Note 1
Key Size: 2048
Public key hash: 80829EC52FC5BA910F4764076C20FDCF
Certificate Slot Name: 1 Key Type: rsa
(Private key in certlocal slot 1)
Subject Name: <O=exampleco, OU=IT, C=US, CN=Ada>
Key Size: 2048
Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
partym # ikecert certlocal -l
Local ID Slot Name: 0 Key Type: rsa
Key Size: 2048
Public key hash: 80829EC52FC5BA910F4764076C20FDCFNote 3
Local ID Slot Name: 1 Key Type: rsa-sha1
Key Size: 2048
Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
Local ID Slot Name: 2 Key Type: rsa
Key Size: 2048
Public key hash: 2239A6A127F88EE0CB40F7C24A65B818This check has verified that the partym system has a valid certificate pair.
You can read the public key hash over the telephone.
Compare the hashes from Note 3 on partym in the preceding step with Note 4 on enigma.
enigma # ikecert certdb -l
Certificate Slot Name: 0 Key Type: rsa
(Private key in certlocal slot 0)
Subject Name: <O=exampleco, OU=IT, C=US, CN=Ada>
Key Size: 2048
Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
Certificate Slot Name: 1 Key Type: rsa
(Private key in certlocal slot 1)
Subject Name: <O=exampleco, OU=IT, C=US, CN=enigma>
Key Size: 2048
Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388
Certificate Slot Name: 2 Key Type: rsa
(Private key in certlocal slot 2)
Subject Name: <O=exampleco, OU=IT, C=US, CN=partym>
Key Size: 2048
Public key hash: 80829EC52FC5BA910F4764076C20FDCFNote 4The public key hash and subject name of the last certificate stored in enigma's public certificate database match the private certificate for partym from the preceding step.
Edit the /etc/inet/ike/config file to recognize the certificates.
The administrator of the remote system provides the values for the cert_trust, remote_addr, and remote_id parameters.
# 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 "O=exampleco, OU=IT, C=US, CN=enigma"
# We could also use the Alternate name of the certificate,
# if it was created with one. In this example, the Alternate Name
# is in the format of an IP address:
# cert_trust "192.168.116.16"
## Parameters that may also show up in rules.
p1_xform
{ auth_method preshared oakley_group 5 auth_alg sha256 encr_alg 3des }
p2_pfs 5
{
label "US-partym to JA-enigmax"
local_id_type dn
local_id "O=exampleco, OU=IT, C=US, CN=partym"
remote_id "O=exampleco, OU=IT, C=US, CN=enigma"
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 0.0.0.0/0
p1_xform
{auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
}For the remote parameters, use partym values. Ensure that the value for the label keyword is unique on the local system.
…
{
label "JA-enigmax to US-partym"
local_id_type dn
local_id "O=exampleco, OU=IT, C=US, CN=enigma"
remote_id "O=exampleco, OU=IT, C=US, CN=partym"
local_addr 192.168.116.16
remote_addr 0.0.0.0/0
…partym # svcadm enable ipsec/ike enigma # svcadm enable ipsec/ike
Next Steps
If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy.
Public certificates from a Certificate Authority (CA) require negotiation with an outside organization. The certificates very easily scale to protect a large number of communicating systems.
Before You Begin
You must become an administrator who is assigned the Network IPsec Management rights profile, in addition to the solaris.admin.edit/etc/inet/ike/config authorization. The root role has all of these rights. For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
If you log in remotely, use the ssh command for a secure remote login. For an example, see Example 7-1.
For a description of the arguments to the command, see Step 1 in How to Configure IKE With Self-Signed Public Key Certificates.
# ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname
# ikecert certlocal -kc -m 2048 -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-----
# ikecert certlocal -kc -m 2048 -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-----
The PKI organization can tell you how to submit the certificate request. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your certificate request into the form. When your request has been checked by the organization, the organization issues you the following two certificate objects and a list of revoked certificates:
Your public key certificate – This certificate is based on the request that you submitted to the organization. The request that you submitted is part of this public key certificate. The certificate uniquely identifies you.
A Certificate Authority – The organization's signature. The CA verifies that your public key certificate is legitimate.
A Certificate Revocation List (CRL) – The latest list of certificates that the organization has revoked. The CRL is not sent separately as a certificate object if access to the CRL is embedded in the public key certificate.
When a URI for the CRL is embedded in the public key certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN (directory name on an LDAP server) entry is embedded in the public key certificate, IKE can retrieve and cache the CRL from an LDAP server that you specify.
See How to Handle a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a public key certificate.
The -a option to the ikecert certdb -a adds the pasted object to the appropriate certificate database on your system. For more information, see IKE With Public Key Certificates.
For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services. If you log in remotely, use the ssh command for a secure remote login. For an example, see Example 7-1.
# ikecert certdb -a < /tmp/PKIcert.eml
# ikecert certdb -a < /tmp/PKIca.eml
# ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D
Use the name that the PKI organization provides.
# 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 sha384 encr_alg aes}
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 sha256 encr_alg aes}
}
Note - All arguments to the auth_method parameter must be on the same line.
Specifically, the enigma ike/config file should do the following:
Include the same cert_root value.
Use enigma values for local parameters.
Use partym values for remote parameters.
Create a unique value for the label keyword. This value must be different from the remote system's label value.
…
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
…Choose the appropriate option:
If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …
The ignore_crls keyword tells IKE not to search for CRLs.
If the PKI organization provides a central distribution point for CRLs, you can modify the ike/config file to point to that location.
See How to Handle a Certificate Revocation List for examples.
Example 10-2 Using rsa_encrypt When Configuring IKE
When you use auth_method rsa_encrypt in the ike/config file, you must add the peer's certificate to the publickeys database.
Send the certificate to the remote system's administrator.
You can paste the certificate into an email.
For example, the partym administrator would send the following email:
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----
The enigma administrator would send the following email:
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----
On each system, add the emailed certificate to the local publickeys database.
# ikecert certdb -a < /tmp/saved.cert.eml
The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides the peer's identity, IKE cannot retrieve the peer's certificate. As a result, the rsa_encrypt method requires that the IKE peers know each other's public keys.
Therefore, when you use an auth_method of rsa_encrypt in the /etc/inet/ike/config file, you must add the peer's certificate to the publickeys database. The publickeys database then holds three certificates for each communicating pair of systems:
Your public key certificate
The CA certificate
The peer's public key certificate
Troubleshooting – The IKE payload, which includes the three certificates, can become too large for rsa_encrypt to encrypt. Errors such as “authorization failed” and “malformed payload” can indicate that the rsa_encrypt method cannot encrypt the total payload. Reduce the size of the payload by using a method, such as rsa_sig, that requires only two certificates.
Next Steps
If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy.
Generating and storing public key certificates on hardware is similar to generating and storing public key certificates on your system. On hardware, the ikecert certlocal and ikecert certdb commands must identify the hardware. The -T option with the token ID identifies the hardware to the commands.
Before You Begin
The hardware must be configured.
The hardware uses the /usr/lib/libpkcs11.so library, unless the pkcs11_path keyword in the /etc/inet/ike/config file points to a different library. The library must be implemented according to the following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), that is, a PKCS #11 library.
See How to Configure IKE to Find the Sun Crypto Accelerator 6000 Board for setup instructions.
You must become an administrator who is assigned the Network IPsec Management rights profile, in addition to the solaris.admin.edit/etc/inet/ike/config authorization. The root role has all of these rights. For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
If you log in remotely, use the ssh command for a secure remote login. For an example, see Example 7-1.
Choose one of the following options:
Note - The Sun Crypto Accelerator 6000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.
# ikecert certlocal -ks -m 2048 -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
The argument to the -T option is the token ID from the attached Sun Crypto Accelerator 6000 board.
# ikecert certlocal -kc -m 2048 -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
For a description of the arguments to the ikecert command, see the ikecert(1M) man page.
If the Sun Crypto Accelerator 6000 board has a user ikemgr whose password is rgm4tigt, you would type the following:
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
Note - The PIN response is stored on disk as clear text.
After you type the password, the certificate prints out:
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----
Choose one of the following options:
You can paste the certificate into an email.
Follow the instructions of the PKI organization to submit the certificate request. For a more detailed discussion, see Step 2 of How to Configure IKE With Certificates Signed by a CA.
Choose one of the following options.
Use the values that the administrator of the remote system provides for the cert_trust, remote_id, and remote_addr parameters. For example, on the enigma system, the ike/config file would appear similar to the following:
# 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
…
{
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 sha256 encr_alg aes}
}Type the name that the PKI organization provides as the value for the cert_root keyword. For example, the ike/config file on the enigma system might appear similar to the following:
# 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"
…
{
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 sha256 encr_alg aes}
}Respond to the PIN request as you responded in Step 2.
Note - You must add the public key certificates to the same attached hardware that generated your private key.
Add the remote system's self-signed certificate. In this example, the certificate is stored in the file, DCA.ACCEL.STOR.CERT.
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password
If the self-signed certificate used rsa_encrypt as the value for the auth_method parameter, add the peer's certificate to the hardware store.
Add the certificate that the organization generated from your certificate request, and add the certificate authority (CA).
# 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
To add a certificate revocation list (CRL) from the PKI organization, see How to Handle a Certificate Revocation List.
Next Steps
If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy.
A certificate revocation list (CRL) contains outdated or compromised certificates from a Certificate Authority. You have four ways to handle CRLs.
You must instruct IKE to ignore CRLs if your CA organization does not issue CRLs. This option is shown in Step 5 in How to Configure IKE With Certificates Signed by a CA.
You can instruct IKE to access the CRLs from a URI (uniform resource indicator) whose address is embedded in the public key certificate from the CA.
You can instruct IKE to access the CRLs from an LDAP server whose DN (directory name) entry is embedded in the public key certificate from the CA.
You can provide the CRL as an argument to the ikecert certrldb command. For an example, see Example 10-3.
The following procedure describes how to instruct IKE to use CRLs from a central distribution point.
Before You Begin
You must become an administrator who is assigned the Network IPsec Management rights profile. For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
# ikecert certdb -lv certspec
Lists certificates in the IKE certificate database.
Lists the certificates in verbose mode. Use this option with care.
Is a pattern that matches a certificate in the IKE certificate database.
For example, the following certificate was issued by Oracle. Details have been altered.
# 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: 2011 Sep 19th, 21:11:11 GMT
Not Valid After: 2015 Sep 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 AccessNotice the CRL Distribution Points entry. The URI entry indicates that this organization's CRL is available on the web. The DN entry indicates that the CRL is available on an LDAP server. Once accessed by IKE, the CRL is cached for further use.
To access the CRL, you need to reach a distribution point.
Add the keyword use_http to the host's /etc/inet/ike/config file. For example, the ike/config file would appear similar to the following:
# Use CRL from organization's URI use_http …
Add the keyword proxy to the ike/config file. The proxy keyword takes a URL as an argument, as in the following:
# Use own web proxy proxy "http://proxy1:8080"
Name the LDAP server as an argument to the ldap-list keyword in the host's /etc/inet/ike/config file. Your organization provides the name of the LDAP server. The entry in the ike/config file would appear similar to the following:
# Use CRL from organization's LDAP ldap-list "ldap1.oracle.com:389,ldap2.oracle.com" …
IKE retrieves the CRL and caches the CRL until the certificate expires.
Example 10-3 Pasting a CRL Into the Local certrldb Database
If the PKI organization's CRL is not available from a central distribution point, you can add the CRL manually to the local certrldb database. Follow the PKI organization's instructions for extracting the CRL into a file, then add the CRL to the database with the ikecert certrldb -a command.
# ikecert certrldb -a < Oracle.Cert.CRL
|