This is used in OpenSSL to form an index to allow certificates in a directory to be looked up by subject name. Alternatively the -nameopt switch may be used more than once to set multiple options.
Calculates and outputs the digest of the DER encoded version of the entire certificate see digest options. This is commonly called a "fingerprint". Because of the nature of message digests, the fingerprint of a certificate is unique to that certificate and two certificates with the same fingerprint can be considered to be the same.
A trusted certificate is an ordinary certificate which has several additional pieces of information attached to it such as the permitted and prohibited uses of the certificate and an "alias". Normally when a certificate is being verified at least one certificate must be "trusted".
By default a trusted certificate must be stored locally and must be a root CA: any certificate chain ending in this CA is then usable for any purpose. Trust settings currently are only used with a root CA. They allow a finer control over the purposes the root CA can be used for.
See the description of the verify utility for more information on the meaning of trust settings. An ordinary or trusted certificate can be input but by default an ordinary certificate is output and any trust settings are discarded. With the -trustout option a trusted certificate is output. A trusted certificate is automatically output if any trust settings are modified. This will allow the certificate to be referred to using a nickname for example "Steve's Certificate".
As of OpenSSL 1. Other OpenSSL applications may define additional uses. It accepts the same values as the -addtrust option. The x utility can be used to sign certificates and requests: it can thus behave like a "mini CA".
If the input file is a certificate it sets the issuer name to the subject name i. The start date is set to the current time and the end date is set to a value determined by the -days option. Any certificate extensions are retained unless the -clrext option is supplied; this includes, for example, any existing key identifier extensions. If the input is a certificate request then a self signed certificate is created using the supplied private key using the subject name in the request.
This option is used when a certificate is being created from another certificate for example with the -signkey or the -CA options. Normally all extensions are retained. The default is 30 days. The -signkey option is used to pass the required private key. With this option a certificate request is expected instead. This option can be used with either the -signkey or -CA options. If used in conjunction with the -CA option the serial number file as specified by the -CAserial or -CAcreateserial options is not used.
When this option is present x behaves like a "mini CA". The input file is signed by this CA using this option: that is its issuer name is set to the subject name of the CA and it is digitally signed using the CAs private key.
This option is normally combined with the -req option. Without the -req option the input is a certificate which must be self signed. If this option is not specified then it is assumed that the CA private key is present in the CA certificate file.
When the -CA option is used to sign a certificate it uses a serial number specified in a file. This file consists of one line containing an even number of hex digits with the serial number to use.
After each use the serial number is incremented and written out to the file again. The default filename consists of the CA certificate file base name with ". For example if the CA certificate file is called "mycacert. If the -CA option is specified and the serial number file does not exist a random number is generated; this is the recommended practice. If not specified then no extensions are added to the certificate.
As mentioned above, RFC profiles certificate revocation lists CRLs , time-stamped lists of revoked certificates that can be queried by browsers and other client software. Common applications of X. This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
For more information read our Cookie and privacy statement. Select Language. Powered by Translate. What Is an X. Need a certificate? Note: Not all applications of X. For example, a company can issue its own privately trusted certificates for internal use. For more information, please read our article on Private vs. Public PKI. Go to top. What is an X. Public key certificates are documented by RFC They are digitally signed and, in general, contain the following information:.
Over time there have been three certificate versions. Each version adds fields to the one before. Version 3 is current and contains version 1 and version 2 fields in addition to version 3 fields. Version 1 defined the following fields:. Version 2 added the following fields containing information about the certificate issuer. These fields are, however, rarely used. Certificates can be saved in a variety of formats. A PEM certificate. Contains a baseencoded DER key with possibly additional metadata about the algorithm used for password protection.
0コメント