diff options
Diffstat (limited to 'usr/src/man/man1m/ikecert.1m')
| -rw-r--r-- | usr/src/man/man1m/ikecert.1m | 1027 |
1 files changed, 0 insertions, 1027 deletions
diff --git a/usr/src/man/man1m/ikecert.1m b/usr/src/man/man1m/ikecert.1m deleted file mode 100644 index da2a53cd08..0000000000 --- a/usr/src/man/man1m/ikecert.1m +++ /dev/null @@ -1,1027 +0,0 @@ -'\" te -.\" Copyright (C) 2009, Sun Microsystems, Inc. All Rights Reserved. -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. -.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with -.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IKECERT 1M "June 20, 2021" -.SH NAME -ikecert \- manipulates the machine's on-filesystem public-key certificate -databases -.SH SYNOPSIS -.nf -\fBikecert\fR certlocal - [\fB-a\fR | \fB-e\fR | \fB-h\fR | \fB-k\fR | \fB-l\fR | \fB-r\fR | \fB-U\fR | \fB-C\fR | \fB-L\fR] - [[\fB-p\fR] \fB-T\fR \fIPKCS#11 token identifier\fR] - [\fIoption_specific_arguments\fR]... -.fi - -.LP -.nf -\fBikecert\fR certdb [\fB-a\fR | \fB-e\fR | \fB-h\fR | \fB-l\fR | \fB-r\fR | \fB-U\fR | \fB-C\fR | \fB-L\fR] - [[\fB-p\fR] \fB-T\fR \fIPKCS#11 token identifier\fR] - [\fIoption_specific_arguments\fR]... -.fi - -.LP -.nf -\fBikecert\fR certrldb [\fB-a\fR | \fB-e\fR | \fB-h\fR | \fB-l\fR | \fB-r\fR] - [\fIoption_specific_arguments\fR]... -.fi - -.LP -.nf -\fBikecert\fR tokens -.fi - -.SH DESCRIPTION -The \fBikecert\fR command manipulates the machine's on-filesystem public-key -certificate databases. See the "Files" section, below. -.sp -.LP -\fBikecert\fR has three subcommands, one for each of the three major -repositories, plus one for listing available hardware tokens: -.RS +4 -.TP -.ie t \(bu -.el o -\fBcertlocal\fR deals with the private-key repository, -.RE -.RS +4 -.TP -.ie t \(bu -.el o -\fBcertdb\fR deals with the public-key repository, and: -.RE -.RS +4 -.TP -.ie t \(bu -.el o -\fBcertrldb\fR deals with the certificate revocation list (\fBCRL\fR) -repository. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -\fBtokens\fR shows the available PKCS#11 tokens for a given PKCS#11 library. -.RE -.sp -.LP -The only supported PKCS#11 library and hardware is the Sun Cryptographic -Accelerator 4000. -.SH OPTIONS -Except for \fBtokens\fR, each subcommand requires one option, possibly followed -by one or more option-specific arguments. -.sp -.LP -The \fBtokens\fR subcommand lists all available tokens in the PKCS#11 library -specified in \fB/etc/inet/ike/config\fR. -.sp -.LP -The following options are supported: -.sp -.ne 2 -.na -\fB\fB-a\fR\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, this option installs (adds) -a private key into the Internet Key Exchange (\fBIKE\fR) local \fBID\fR -database. The key data is read from standard input, and is in either -Solaris-only format or unencrypted PKCS#8 DER format. Key format is -automatically detected. PKCS#8 key files in PEM format and files in password -protected, encrypted format are not recognized, but can be converted -appropriately using tools available in OpenSSL. -.sp -This option cannot be used with PKCS#11 hardware objects when the corresponding -public certificate is not already present in the \fBIKE\fR database. When -importing both a public certificate and a private key, the public portion must -be imported first using the \fBcertdb\fR subcommand. -.RE - -.sp -.ne 2 -.na -\fBcertdb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertdb\fR subcommand, this option reads a -certificate from standard input and adds it to the \fBIKE\fR certificate -database. The certificate must be a \fBX.509\fR certificate in \fBPEM Base64\fR -or \fBASN.1 BER\fR encoding. The certificate adopts the name of its identity. -.sp -This option can import a certificate into a PKCS#11 hardware key store one of -two ways: Either a matching public key object \fBand\fR an existing private key -object were created using the \fBcertlocal\fR \fB-kc\fR option, or if a PKCS#11 -token is explicitly specified using the \fB-T\fR option. -.RE - -.sp -.ne 2 -.na -\fBcertrldb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertrldb\fR subcommand, this option installs (adds) -a \fBCRL\fR into the \fBIKE\fR database. The \fBCRL\fR reads from standard -input. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-e\fR [\fB-f\fR pkcs8] \fIslot\fR\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, this option extracts a -private key from the \fBIKE\fR local \fBID\fR database. The key data are -written to standard output. The slot specifies which private key to extract. -Private keys are only extracted in binary/ber format. -.sp -\fBUse this option with extreme caution.\fR See the "Security" section, below. -.sp -This option will not work with PKCS#11 hardware objects. -.sp -When used in conjunction with "\fB-f\fR \fBpkcs8\fR", the private key is -extracted in unencrypted PKCS#8 format. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-e\fR [\fB-f\fR \fIoutput-format\fR] \fBcertspec\fR\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertdb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertdb\fR subcommand, this option extracts a -certificate from the IKE certificate database which matches the certspec and -writes it to standard output. The \fIoutput-format\fR option specifies the -encoding format. Valid options are \fBPEM\fR and \fBBER\fR. This extracts the -first matching identity. The default output format is \fBPEM\fR. -.RE - -.sp -.ne 2 -.na -\fBcertrldb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertrldb\fR subcommand, this option extracts a -\fBCRL\fR from the IKE database. The key data are written to standard output. -The \fBcertspec\fR specifies which CRL that is extracted. The first one that -matches in the database is extracted. See \fBNOTES\fR, below, for details on -\fBcertspec\fR patterns. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-kc\fR \fB-m\fR \fIkeysize\fR \fB-t\fR \fIkeytype\fR \fB-D\fR \fIdname\fR -\fB-A\fR \fIaltname\fR[ ... ]\fR -.ad -.br -.na -\fB[\fB-S\fR \fIvalidity start_time\fR][\fB-F\fR \fIvalidity end_time\fR]\fR -.ad -.br -.na -\fB[\fB-T\fR \fIPKCS#11 token identifier\fR]\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, this option generates a IKE -public/private key pair and adds it into the local ID database. It also -generates a certificate request and sends that to standard output. For details -on the above options see for details on the \fIdname\fR argument and see -ALTERNATIVE NAMES for details on the \fIaltname\fR argument(s) to this command. -.sp -If \fB-T\fR is specified, the hardware token will generate the pair of keys. -.sp -If \fB-p\fR is specified with \fB-T\fR, the PKCS#11 token pin is stored in the -clear on-disk, with root-protected file permissions. If not specified, one must -unlock the token with \fBikeadm\fR(1M) once \fBin.iked\fR(1M) is running. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-ks\fR \fB-m\fR \fIkeysize\fR \fB-t\fR \fIkeytype\fR \fB-D\fR \fIdname\fR -\fB-A\fR \fIaltname\fR[ ... ]\fR -.ad -.br -.na -\fB[\fB-S\fR \fIvalidity start_time\fR][\fB-F\fR \fIvalidity end_time\fR]\fR -.ad -.br -.na -\fB[\fB-f\fR \fIoutput-format\fR][[\fB-p\fR] \fB-T\fR \fIPKCS#11 token -identifier\fR]\fR -.ad -.br -.na -\fB\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, generates a public/private -key pair and adds it into the local ID database. This option also generates a -self-signed certificate and installs it into the certificate database. See -\fBNOTES\fR, below, for details on the \fIdname\fR and \fIaltname\fR arguments -to this command. -.sp -If \fB-T\fR is specified, the hardware token will generate the pair of keys, -and the self-signed certificate will also be stored in the hardware. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-l\fR [\fB-v\fR] [\fIslot\fR]\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, this option lists private -keys in the local ID database. The \fB-v\fR option switches output to a verbose -mode where the entire certificate is printed. -.sp -\fBUse the\fR \fB-v\fR\fBoption with extreme caution.\fR See the "Security" -section, below. The \fB-v\fR option will not work with PKCS#11 hardware -objects. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-l\fR [\fB-v\fR] [certspec]\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertdb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertdb\fR subcommand, this option lists certificates -in the IKE certificate database matching the certspec, if any pattern is given. -The list displays the identity string of the certificates, as well as, the -private key if in the key database. The \fB-v\fR switches the output to a -verbose mode where the entire certificate is printed. -.sp -If the matching certificate is on a hardware token, the token ID is also -listed. -.RE - -.sp -.ne 2 -.na -\fBcertrldb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertrldb\fR subcommand, this option lists the CRLs -in the IKE database along with any certificates that reside in the database and -match the Issuer Name. \fBcertspec\fR can be used to specify to list a specific -CRL. The \fB-v\fR option switches the output to a verbose mode where the entire -certificate is printed. See \fBNOTES\fR, below, for details on \fBcertspec\fR -patterns. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-r\fR \fIslot\fR\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, deletes the local ID in the -specified slot. If there is a corresponding public key, it is not be deleted. -If this slot is deemed as "corrupted" or otherwise unrecognizable, it is -deleted as well. -.sp -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 \fBcertdb\fR \fB-r\fR, that is not a problem. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-r\fR certspec\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertdb\fR -.ad -.sp .6 -.RS 4n -Removes certificates from the IKE certificate database. Certificates matching -the specified certificate pattern are deleted. Any private keys in the -\fBcertlocal\fR database corresponding to these certificates are not deleted. -This removes the first matching identity. -.sp -If the pattern specifies a slot and the slot is deemed as "corrupted" or -otherwise unrecognizable, it is deleted as well. -.sp -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 \fBcertlocal\fR \fB-r\fR, that is not a problem. -.RE - -.sp -.ne 2 -.na -\fBcertrldb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertrldb\fR subcommand, this option deletes the CRL -with the given \fBcertspec\fR. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-U\fR slot\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fB\fBcertlocal\fR\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand and the \fB-T\fR flag, this -option unlinks a PKCS#11 private key object from the IKE database. There will -be no attempt to access the hardware keystore or to validate or remove the -on-token private key object. The object is simply disassociated from the IKE -database. -.RE - -.sp -.ne 2 -.na -\fB\fBcertdb\fR\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertdb\fR subcommand and the \fB-T\fR flag, this -option unlinks a PKCS#11 certificate object from the IKE database. There will -be no attempt to access the hardware keystore or to validate or remove the -on-token certificate or public key objects. The objects are simply -disassociated from the IKE database. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-C\fR certspec\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, this option copies both the -private key and its corresponding certificate and the public key from the -on-disk keystore to the hardware keystore specified by its PKCS#11 token. This -subcommand attempts to create each of these components, even if one part fails. -In all cases, the original on-disk private key and public certificate are still -retained and must be deleted separately. Some hardware keystores, such as -FIPS-140 compliant devices, may not support migration of private key objects in -this manner. -.RE - -.sp -.ne 2 -.na -\fBcertdb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertdb\fR subcommand, this option copies the -certificate matching the given \fBcertspec\fR and corresponding public key from -the on-disk keystore to the hardware keystore specified by its PKCS#11 token. -The original public certificate is still retained and must be deleted -separately, if desired. -.sp -If \fB-p\fR is specified, the PKCS#11 token pin is stored in the clear on-disk, -with root-protected file permissions. If not specified, one must unlock the -token with \fBikeadm\fR(1M) once \fBin.iked\fR(1M) is running. -.RE - -.RE - -.sp -.ne 2 -.na -\fB\fB-L\fR pattern\fR -.ad -.sp .6 -.RS 4n -.sp -.ne 2 -.na -\fBcertlocal\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertlocal\fR subcommand, this option links an -existing on-token private key object to the \fBIKE\fR database. The object -itself remains on the token. This option simply lets the \fBIKE\fR -infrastructure know that the object exists, as if it had been originally -created on-token with the Solaris \fBIKE\fR utilities. -.RE - -.sp -.ne 2 -.na -\fBcertdb\fR -.ad -.sp .6 -.RS 4n -When specified with the \fBcertdb\fR subcommand, this option links an existing -on-token certificate object to the \fBIKE\fR database. The object itself -remains on the token. This option simply lets the \fBIKE\fR infrastructure know -that the object exists, as if it had been originally created on-token with the -Solaris \fBIKE\fR utilities. -.sp -If \fB-p\fR is specified, the PKCS#11 token pin is stored in the clear on-disk, -with root-protected file permissions. If not specified, one must unlock the -token with \fBikeadm\fR(1M) once \fBin.iked\fR(1M) is running. -.RE - -.RE - -.SH PARAMETERS -The following parameters are supported: -.sp -.ne 2 -.na -\fBcertspec\fR -.ad -.sp .6 -.RS 4n -Specifies the pattern matching of certificate specifications. Valid -\fBcertspec\fRs are the Subject Name, Issuer Name, and Subject Alternative -Names. -.sp -These can be specified as certificates that match the given \fBcertspec\fR -values and that do not match other \fBcertspec\fR values. To signify a -\fBcertspec\fR value that is not supposed to be present in a certificate, place -an \fB!\fR in front of the tag. -.sp -Valid \fBcertspec\fRs are: -.sp -.in +2 -.nf -<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 -.fi -.in -2 -.sp - -Valid arguments to the alternative names are as follows: -.sp -.in +2 -.nf -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> -.fi -.in -2 -.sp - -Valid Slot numbers can be specified without the keyword tag. Alternative name -can also be issued with keyword tags. -.RE - -.sp -.ne 2 -.na -\fB\fB-A\fR\fR -.ad -.sp .6 -.RS 4n -Subject Alternative Names the certificate. The argument that follows the -\fB-A\fR option should be in the form of \fItag\fR=\fIvalue\fR. Valid tags are -\fBIP\fR, \fBDNS\fR, \fBEMAIL\fR, \fBURI\fR, \fBDN\fR, and \fBRID\fR (See -example below). -.RE - -.sp -.ne 2 -.na -\fB\fB-D\fR\fR -.ad -.sp .6 -.RS 4n -\fBX.509\fR distinguished name for the certificate subject. It typically has -the form of: \fBC\fR=country, \fBO\fR=organization, \fBOU\fR=organizational -unit, \fBCN\fR=common name. Valid tags are: \fBC\fR, \fBO\fR, \fBOU\fR, and -\fBCN\fR. -.RE - -.sp -.ne 2 -.na -\fB\fB-f\fR\fR -.ad -.sp .6 -.RS 4n -Encoding output format. \fBpem\fR for \fBPEM Base64\fR or \fBber\fR for -\fBASN.1 BER\fR. If \fB-f\fR is not specified, \fBpem\fR is assumed. -.RE - -.sp -.ne 2 -.na -\fB\fB-F\fR \fIvalidity end_time\fR\fR -.ad -.sp .6 -.RS 4n -Finish certificate validity time. If the \fB-F\fR flag is not specified, the -validity end time is calculated at four years from the validity start time. See -\fBNOTES\fR for an explanation for the validity date and time syntax. -.RE - -.sp -.ne 2 -.na -\fB\fB-m\fR\fR -.ad -.sp .6 -.RS 4n -Key size. It can be \fB512\fR, \fB1024\fR, \fB2048\fR, \fB3072\fR, or -\fB4096\fR. Use the following command to determine the key sizes supported by -the Solaris Cryptographic Framework: -.sp -.in +2 -.nf -% \fBcryptoadm list -vm\fR -.fi -.in -2 -.sp - -The mechanisms displayed by the preceding command are described in -\fBpkcs11_softtoken\fR(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: -.sp -.in +2 -.nf -CKM_RSA_PKCS_KEY_PAIR_GEN -CKM_DSA_KEY_PAIR_GEN -CKM_DH_PKCS_KEY_PAIR_GEN -.fi -.in -2 -.sp - -.LP -Note - -.sp -.RS 2 -Some hardware does not support all key sizes. For example, the Sun -Cryptographic Accelerator 4000's keystore (when using the \fB-T\fR option, -below), supports only up to 2048-bit keys for RSA and 1024-bit keys for DSA. -.RE -.RE - -.sp -.ne 2 -.na -\fB\fB-S\fR \fIvalidity start_time\fR\fR -.ad -.sp .6 -.RS 4n -Start certificate validity time. If the \fB-S\fR flag is not specified, the -current date and time is used for the validity start time. See \fBNOTES\fR, -below, for an explanation for the validity date and time syntax. -.RE - -.sp -.ne 2 -.na -\fB\fB-t\fR\fR -.ad -.sp .6 -.RS 4n -Key type. It can be \fBrsa-sha1\fR, \fBrsa-md5\fR, or \fBdsa-sha1\fR. -.RE - -.sp -.ne 2 -.na -\fB\fB-T\fR\fR -.ad -.sp .6 -.RS 4n -PKCS#11 token identifier for hardware key storage. This specifies a hardware -device instance in conformance to the PKCS#11 standard. A PKCS#11 library must -be specified in \fB/etc/inet/ike/config\fR. (See \fBike.config\fR(4).) -.sp -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. -.sp -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 \fB/etc/inet/ike/config\fR. There can be -multiple tokens (each with individual key storage) for a single PKCS#11 library -instance. -.RE - -.SH SECURITY -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. -.sp -.LP -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 desirable. The token's PIN, however, is still needed. The PIN for -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, \fBpossession\fR of the key is still -unavailable, only \fBuse\fR of the key is an issue if the host is compromised. -Beyond the PIN, the security of \fBikecert\fR then reduces to the security of -the PKCS#11 implementation. The PKCS#11 implementation should be scrutinized -also. -.sp -.LP -Refer to the afterword by Matt Blaze in Bruce Schneier's \fIApplied -Cryptography: Protocols, Algorithms, and Source Code in C\fR for additional -information. -.SH EXAMPLES -\fBExample 1 \fRGenerating a Self-Signed Certificate -.sp -.LP -The following is an example of a self-signed certificate: - -.sp -.in +2 -.nf -example# \fBikecert certlocal -ks -m 512 -t rsa-md5 -D "C=US, O=SUN" -A\fR -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----- -.fi -.in -2 -.sp - -.LP -\fBExample 2 \fRGenerating a CA Request -.sp -.LP -Generating a \fBCA\fR request appears the same as the self-signed certificate. -The only differences between the two is the option \fB-c\fR instead of -\fB-s\fR, and the certificate data is a \fBCA\fR request. - -.sp -.in +2 -.nf -example# \fBikecert certlocal -kc -m 512 -t rsa-md5 \e - -D "C=US, O=SUN" -A IP=1.2.3.4\fR -.fi -.in -2 -.sp - -.LP -\fBExample 3 \fRA CA Request Using a Hardware Key Store -.sp -.LP -The following example illustrates the specification of a token using the -\fB-T\fR option. - -.sp -.in +2 -.nf -example# \fB# ikecert certlocal -kc -m 1024 -t rsa-md5 -T vca0-keystore \e - -D "C=US, O=SUN" -A IP=1.2.3.4\fR -.fi -.in -2 -.sp - -.SH EXIT STATUS -The following exit values are returned: -.sp -.ne 2 -.na -\fB\fB0\fR\fR -.ad -.sp .6 -.RS 4n -Successful completion. -.RE - -.sp -.ne 2 -.na -\fB\fBnon-zero\fR\fR -.ad -.sp .6 -.RS 4n -An error occurred. Writes an appropriate error message to standard error. -.RE - -.SH FILES -.ne 2 -.na -\fB\fB/etc/inet/secret/ike.privatekeys/*\fR\fR -.ad -.sp .6 -.RS 4n -Private keys. A private key \fBmust\fR have a matching public-key certificate -with the same filename in \fB/etc/inet/ike/publickeys/\fR. -.RE - -.sp -.ne 2 -.na -\fB\fB/etc/inet/ike/publickeys/*\fR\fR -.ad -.sp .6 -.RS 4n -Public-key certificates. The names are only important with regard to matching -private key names. -.RE - -.sp -.ne 2 -.na -\fB\fB/etc/inet/ike/crls/*\fR\fR -.ad -.sp .6 -.RS 4n -Public key certificate revocation lists. -.RE - -.sp -.ne 2 -.na -\fB\fB/etc/inet/ike/config\fR\fR -.ad -.sp .6 -.RS 4n -Consulted for the pathname of a PKCS#11 library. -.RE - -.SH ATTRIBUTES -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -_ -Interface Stability Evolving -.TE - -.SH SEE ALSO -\fBikeadm\fR(1M), \fBin.iked\fR(1M), \fBgetdate\fR(3C), \fBike.config\fR(4), -\fBattributes\fR(5), \fBpkcs11_softtoken\fR(5) -.sp -.LP -Schneier, Bruce. \fIApplied Cryptography: Protocols, Algorithms, and Source -Code in C\fR. Second Edition. John Wiley & Sons. New York, NY. 1996. -.sp -.LP -RSA Labs, PKCS#11 v2.11: \fICryptographic Token Interface Standards\fR, -November 2001. -.SH NOTES -The following is the validity date and time syntax when the \fB-F\fR or -\fB-S\fR flags are used: -.sp -.LP -For relative dates, the syntax is as follows: -.sp -.in +2 -.nf -{+,-}[Ns][Nm][Nh][Nd][Nw][NM][Ny] -.fi -.in -2 -.sp - -.sp -.LP -where: -.sp -.ne 2 -.na -\fBN\fR -.ad -.sp .6 -.RS 4n -represents an integer -.RE - -.sp -.ne 2 -.na -\fBs\fR -.ad -.sp .6 -.RS 4n -represents seconds -.RE - -.sp -.ne 2 -.na -\fBm\fR -.ad -.sp .6 -.RS 4n -represents minutes -.RE - -.sp -.ne 2 -.na -\fBh\fR -.ad -.sp .6 -.RS 4n -represents hours -.RE - -.sp -.ne 2 -.na -\fBd\fR -.ad -.sp .6 -.RS 4n -represents days -.RE - -.sp -.ne 2 -.na -\fBw\fR -.ad -.sp .6 -.RS 4n -represents weeks -.RE - -.sp -.ne 2 -.na -\fBM\fR -.ad -.sp .6 -.RS 4n -represents months -.RE - -.sp -.ne 2 -.na -\fBy\fR -.ad -.sp .6 -.RS 4n -represents years -.RE - -.sp -.LP -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. -.sp -.LP -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. -.sp -.LP -For absolute dates, the syntax of the date formats included in the file -\fB/etc/datemsk\fR are accepted (See \fBgetdate\fR(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. -.sp -.in +2 -.nf -# ikecert certlocal -ks -t rsa-sha1 -m 1024 \e - -D "CN=mycert, O=Sun, C=US" \e - -S -1d2h -F "01/22/2007 12:00:00" -.fi -.in -2 -.sp - -.sp -.LP -As \fBin.iked\fR(1M) can run only in the global zone and exclusive-IP zones, -this command is not useful in shared-IP zones. |