ikecert - manipulates the machine's on-filesystem public-key certificate databases
ikecert certlocal [-a | -e | -h | -k | -l | -r | -U | -C | -L] [-T PKCS#11 token identifier] [option_specific_arguments]...
ikecert certdb [-a | -e | -h | -l | -r | -U | -C | -L] [-T PKCS#11 token identifier] [option_specific_arguments]...
ikecert certrldb [-a | -e | -h | -l | -r] [option_specific_arguments]...
ikecert tokens
The ikecert command manipulates the machine's on-filesystem public-key certificate databases. See .
ikecert has three subcommands, one for each of the three major repositories, plus one for listing available hardware tokens:
The only supported PKCS#11 library and hardware is the Sun Cryptographic Accelerator 4000.
Except for tokens, each subcommand requires one option, possibly followed by one or more option-specific arguments.
The tokens subcommand lists all available tokens in the PKCS#11 library specified in /etc/inet/ike/config.
The following options are supported:
-a
certlocal
This option cannot be used with PKCS#11 hardware objects when the corresponding public certificate is not already present in the IKE database. When importing both a public certificate and a private key, the public portion must be imported first using the certdb subcommand.
certdb
This option can import a certificate into a PKCS#11 hardware key store one of two ways: Either a matching public key object and an existing private key object were created using the certlocal -kc option, or if a PKCS#11 token is explicitly specified using the -T option.
certrldb
-e [-f pkcs8] slot
certlocal
Use this option with extreme caution. See .
This option will not work with PKCS#11 hardware objects.
When used in conjunction with "-f pkcs8", the private key is extracted in unencrypted PKCS#8 format.
-e [-f output-format] certspec
certdb
certrldb
-kc -m keysize -t keytype -D dname -A altname[ ... ]
[-S validity start_time][-F validity end_time]
[-T PKCS#11 token identifier]
certlocal
If -T is specified, the hardware token will generate the pair of keys.
-ks -m keysize -t keytype -D dname -A altname[ ... ]
[-S validity start_time][-F validity end_time]
[-f output-format][-T PKCS#11 token identifier]
certlocal
If -T is specified, the hardware token will generate the pair of keys, and the self-signed certificate will also be stored in the hardware.
-l [-v] [slot]
certlocal
Use the -voption with extreme caution. See . The -v option will not work with PKCS#11 hardware objects.
-l [-v] [certspec]
certdb
If the matching ceritifcate is on a hardware token, the token ID is also listed.
certrldb
-r slot
certlocal
If this is invoked on a PKCS#11 hardware object, it will also delete the PKCS#11 public key and private key objects. If the public key object was already deleted by certdb -r, that is not a problem.
-r certspec
certdb
If the pattern specifies a slot and the slot is deemed as "corrupted" or otherwise unrecognizable, it is deleted as well.
If this is invoked on a PKCS#11 hardware object, it will also delete the certificate and the PKCS#11 public key object. If the public key object was already deleted by certlocal -r, that is not a problem.
certrldb
-U slot
certlocal
certdb
-C certspec
certlocal
certdb
-L pattern
certlocal
certdb
The following parameters are supported:
certspec
These can be specified as certificates that match the given certspec values and that do not match other certspec values. To signify a certspec value that is not supposed to be present in a certificate, place an ! in front of the tag.
Valid certspecs are:
<Subject Names> SUBJECT=<Subject Names> ISSUER=<Issuer Names> SLOT=<Slot Number in the certificate database> Example:"ISSUER=C=US, O=SUN" IP=1.2.3.4 !DNS=example.com Example:"C=US, O=CALIFORNIA" IP=5.4.2.1 DNS=example.com
Valid arguments to the alternative names are as follows:
IP=<IPv4 address> DNS=<Domain Name Server address> EMAIL=<email (RFC 822) address> URI=<Uniform Resource Indicator value> DN=<LDAP Directory Name value> RID=<Registered Identifier value>
Valid Slot numbers can be specified without the keyword tag. Alternative name can also be issued with keyword tags.
-A
-D
-f
-F validity end_time
-m
% cryptoadm list -vm
The mechanisms displayed by the preceding command are described in pkcs11_softtoken(5). If your system has hardware acceleration, the mechanisms supported by the hardware will be listed in a separate section for each provider. Mechanisms can be any of:
CKM_RSA_PKCS_KEY_PAIR_GEN CKM_DSA_KEY_PAIR_GEN CKM_DH_PKCS_KEY_PAIR_GEN
Note -
-S validity start_time
-t
-T
A token identifier is a 32-character space-filled string. If the token given is less than 32 characters long, it will be automatically padded with spaces.
If there is more than one PKCS#11 library on a system, keep in mind that only one can be specified at a time in /etc/inet/ike/config. There can be multiple tokens (each with individual key storage) for a single PKCS#11 library instance.
This command can save private keys of a public-private key pair into a file. Any exposure of a private key may lead to compromise if the key is somehow obtained by an adversary.
The PKCS#11 hardware object functionality can address some of the shortcomings of on-disk private keys. Because IKE is a system service, user intervention at boot is not desireable. The token's PIN, however, is still needed. The PINfor the PKCS#11 token, therefore, is stored where normally the on-disk cryptographic keys would reside. This design decision is deemed acceptable because, with a hardware key store, possession of the key is still unavailable, only use of the key is an issue if the host is compromised. Beyond the PIN, the security of ikecert then reduces to the security of the PKCS#11 implementation. The PKCS#11 implementation should be scrutinized also.
Refer to the afterword by Matt Blaze in Bruce Schneier's Applied Cryptography: Protocols, Algorithms, and Source Code in C for additional information.
Example 1 Generating a Self-Signed Certificate
The following is an example of a self-signed certificate:
example# ikecert certlocal -ks -m 512 -t rsa-md5 -D "C=US, O=SUN" -A IP=1.2.3.4 Generating, please wait... Certificate generated. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIIBRDCB76ADAgECAgEBMA0GCSqGSIb3DQEBBAUAMBsxCzAJBgNVBAYTAlVTMQww CgYDVQQKEwNTVU4wHhcNMDEwMzE0MDEzMDM1WhcNMDUwMzE0MDEzMDM1WjAbMQsw CQYDVQQGEwJVUzEMMAoGA1UEChMDU1VOMFowDQYJKoZIhvcNAQEBBQADSQAwRgJB APDhqpKgjgRoRUr6twTMTtSuNsReEnFoReVer!ztpXpQK6ybYlRH18JIqU/uCV/r 26R/cVXTy5qc5NbMwA40KzcCASOjIDAeMAsGA1UdDwQEAwIFoDAPBgNVHREECDAG hwQBAgMEMA0GCSqGSIb3DQEBBAUAA0EApTRD23KzN95GMvPD71hwwClukslKLVg8 f1xm9ZsHLPJLRxHFwsqqjAad4j4wwwriiUmGAHLTGB0lJMl8xsgxag== -----END X509 CERTIFICATE-----
Example 2 Generating a CA Request
Generating a CA request appears the same as the self-signed certificate. The only differences between the two is the option -c instead of -s, and the certificate data is a CA request.
example# ikecert certlocal -kc -m 512 -t rsa-md5 \ -D "C=US, O=SUN" -A IP=1.2.3.4
Example 3 A CA Request Using a Hardware Key Store
The following example illustrates the specification of a token using the -T option.
example# # ikecert certlocal -kc -m 1024 -t rsa-md5 -T vca0-keystore \ -D "C=US, O=SUN" -A IP=1.2.3.4
The following exit values are returned:
0
non-zero
/etc/inet/secret/ike.privatekeys/*
/etc/inet/ike/publickeys/*
/etc/inet/ike/crls/*
/etc/inet/ike/config
See attributes(5) for descriptions of the following attributes:
|
in.iked(1M), getdate(3C), ike.config(4), attributes(5), pkcs11_softtoken(5)
Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. Second Edition. John Wiley & Sons. New York, NY. 1996.
RSA Labs, PKCS#11 v2.11: Cryptographic Token Interface Standards, November 2001.
The following is the validity date and time syntax when the -F or -S flags are used:
For relative dates, the syntax is as follows:
{+,-}[Ns][Nm][Nh][Nd][Nw][NM][Ny]
where
N
s
m
h
d
w
M
y
These parameters can be given in any order. For example, "+3d12h" is three and a half days from now, and "-3y2M" is three years and 2 months ago.
All parameters with fixed values can be added up in absolute seconds. Months and years, which have variable numbers of seconds, are calculated using calendar time. Months and years, which are not of fixed length, are defined such that adding a year or month means the same day next year or month. For instance, if it is Jan 26, 2005 and the certificate should expire 3 years and 1 month from today, the expiration (end validity time) date will be Feb 26, 2008. Overflows are dealt with accordingly. For example, one month from Jan 31, 2005 is March 3, 2005, since February has only 28 days.
For absolute dates, the syntax of the date formats included in the file /etc/datemsk are accepted (See getdate(3C) for details). Any date string prepended with a "+" or "-" is treated as a time relative to the current time, while others are treated as absolute dates. Sanity checking is also done to ensure that the end validity date is greater than the start validity date. For example, the following command would create a certificate with start date 1 day and 2 hours ago and an end date of Jan 22nd, 2007 at 12:00:00 local time.
# ikecert certlocal -ks -t rsa-sha1 -m 1024 \ -D "CN=mycert, O=Sun, C=US" \ -S -1d2h -F "01/22/2007 12:00:00"
As in.iked(1M) can run only in the global zone and exclusive-IP zones, this command is not useful in shared-IP zones.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |