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.
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
Examples:
extendedKeyUsage=critical,codeSigning,1.2.3.4
- extendedKeyUsage=nsSGC,msSGC
+ extendedKeyUsage=serverAuth,clientAuth
=head2 Subject Key Identifier.
The value of B<dirName> should point to a section containing the distinguished
name to use as a set of name value pairs. Multi values AVAs can be formed by
-preceeding the name with a B<+> character.
+prefacing the name with a B<+> character.
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:
O=Organisation
CN=Some Name
-
+
=head2 Certificate Policies.
This is a I<raw> extension. All the fields of this extension can be set by
=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:
nameConstraints=permitted;email:.somedomain.com
nameConstraints=excluded;email:.com
-issuingDistributionPoint = idp_section
+
=head2 OCSP No Check
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
-
-The B<directoryName> and B<otherName> option as well as the B<ASN1> option
-for arbitrary extensions was added in OpenSSL 0.9.8
-
=head1 SEE ALSO
-L<req(1)|req(1)>, L<ca(1)|ca(1)>, L<x509(1)|x509(1)>,
-L<ASN1_generate_nconf(3)|ASN1_generate_nconf(3)>
+L<req(1)>, L<ca(1)>, L<x509(1)>,
+L<ASN1_generate_nconf(3)>
=cut