Key usage is a multi valued extension consisting of a list of names of the
permitted key usages.
-The supporte names are: digitalSignature, nonRepudiation, keyEncipherment,
+The supported names are: digitalSignature, nonRepudiation, keyEncipherment,
dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly
and decipherOnly.
This extensions consists of a list of usages indicating purposes for which
the certificate public key can be used for,
-These can either be object short names of the dotted numerical form of OIDs.
+These can either be object short names or the dotted numerical form of OIDs.
While any OID can be used only certain values make sense. In particular the
following PKIX, NS and MS values are meaningful:
- Value Meaning
- ----- -------
- serverAuth SSL/TLS Web Server Authentication.
- clientAuth SSL/TLS Web Client Authentication.
- codeSigning Code signing.
- emailProtection E-mail Protection (S/MIME).
- timeStamping Trusted Timestamping
- msCodeInd Microsoft Individual Code Signing (authenticode)
- msCodeCom Microsoft Commercial Code Signing (authenticode)
- msCTLSign Microsoft Trust List Signing
- msSGC Microsoft Server Gated Crypto
- msEFS Microsoft Encrypted File System
- nsSGC Netscape Server Gated Crypto
+ Value Meaning
+ ----- -------
+ serverAuth SSL/TLS Web Server Authentication.
+ clientAuth SSL/TLS Web Client Authentication.
+ codeSigning Code signing.
+ emailProtection E-mail Protection (S/MIME).
+ timeStamping Trusted Timestamping
+ OCSPSigning OCSP Signing
+ ipsecIKE ipsec Internet Key Exchange
+ msCodeInd Microsoft Individual Code Signing (authenticode)
+ msCodeCom Microsoft Commercial Code Signing (authenticode)
+ msCTLSign Microsoft Trust List Signing
+ msEFS Microsoft Encrypted File System
Examples:
extendedKeyUsage=critical,codeSigning,1.2.3.4
- extendedKeyUsage=nsSGC,msSGC
+ extendedKeyUsage=serverAuth,clientAuth
=head2 Subject Key Identifier.
otherName can include arbitrary data associated with an OID: the value
should be the OID followed by a semicolon and the content in standard
-L<ASN1_generate_nconf(3)|ASN1_generate_nconf(3)> format.
+L<ASN1_generate_nconf(3)> format.
Examples:
The issuer alternative name option supports all the literal options of
subject alternative name. It does B<not> support the email:copy option because
that would not make sense. It does support an additional issuer:copy option
-that will copy all the subject alternative name values from the issuer
+that will copy all the subject alternative name values from the issuer
certificate (if possible).
Example:
authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html
-=head2 CRL distribution points.
+=head2 CRL distribution points
This is a multi-valued extension whose options can be either in name:value pair
using the same form as subject alternative name or a single value representing
=head2 Policy Constraints
This is a multi-valued extension which consisting of the names
-B<requireExplicitPolicy> or B<inhibitPolicyMapping> and a non negative intger
+B<requireExplicitPolicy> or B<inhibitPolicyMapping> and a non negative integer
value. At least one component must be present.
Example:
The name constraints extension is a multi-valued extension. The name should
begin with the word B<permitted> or B<excluded> followed by a B<;>. The rest of
the name and the value follows the syntax of subjectAltName except email:copy
-is not supported and the B<IP> form should consist of an IP addresses and
+is not supported and the B<IP> form should consist of an IP addresses and
subnet mask separated by a B</>.
Examples:
noCheck = ignored
+=head2 TLS Feature (aka Must Staple)
+
+This is a multi-valued extension consisting of a list of TLS extension
+identifiers. Each identifier may be a number (0..65535) or a supported name.
+When a TLS client sends a listed extension, the TLS server is expected to
+include that extension in its reply.
+
+The supported names are: B<status_request> and B<status_request_v2>.
+
+Example:
+
+ tlsfeature = status_request
+
+
=head1 DEPRECATED EXTENSIONS
The following extensions are non standard, Netscape specific and largely
There are two ways to encode arbitrary extensions.
The first way is to use the word ASN1 followed by the extension content
-using the same syntax as L<ASN1_generate_nconf(3)|ASN1_generate_nconf(3)>.
+using the same syntax as L<ASN1_generate_nconf(3)>.
For example:
1.2.3.4=critical,ASN1:UTF8String:Some random data
[subject_alt_section]
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
-is valid.
+is valid.
Due to the behaviour of the OpenSSL B<conf> library the same field name
can only occur once in a section. This means that:
email.1=steve@here
email.2=steve@there
-=head1 HISTORY
-
-The X509v3 extension code was first added to OpenSSL 0.9.2.
-
-Policy mappings, inhibit any policy and name constraints support was added in
-OpenSSL 0.9.8
+=head1 SEE ALSO
-The B<directoryName> and B<otherName> option as well as the B<ASN1> option
-for arbitrary extensions was added in OpenSSL 0.9.8
+L<req(1)>, L<ca(1)>, L<x509(1)>,
+L<ASN1_generate_nconf(3)>
-=head1 SEE ALSO
+=head1 COPYRIGHT
-L<req(1)|req(1)>, L<ca(1)|ca(1)>, L<x509(1)|x509(1)>,
-L<ASN1_generate_nconf(3)|ASN1_generate_nconf(3)>
+Copyright 2004-2016 The OpenSSL Project Authors. All Rights Reserved.
+Licensed under the OpenSSL license (the "License"). You may not use
+this file except in compliance with the License. You can obtain a copy
+in the file LICENSE in the source distribution or at
+L<https://www.openssl.org/source/license.html>.
=cut