diff options
author | Rich Salz <rsalz@openssl.org> | 2016-10-26 19:56:48 +0200 |
---|---|---|
committer | Rich Salz <rsalz@openssl.org> | 2016-10-26 19:59:52 +0200 |
commit | 99d63d4662e16afbeff49f29b48f1c87d5558ed0 (patch) | |
tree | 6512ff02cd93985526080f05ab2b5408235b19a9 /doc/man5 | |
parent | VMS: tell the C compiler to use the ISO C94 standard (diff) | |
download | openssl-99d63d4662e16afbeff49f29b48f1c87d5558ed0.tar.xz openssl-99d63d4662e16afbeff49f29b48f1c87d5558ed0.zip |
Move manpages to man[1357] structure.
Move manpages to manX directories
Add Windows/VMS install fix from Richard Levitte
Update README
Fix typo's
Remove some duplicates
Reviewed-by: Richard Levitte <levitte@openssl.org>
Diffstat (limited to 'doc/man5')
-rw-r--r-- | doc/man5/config.pod | 384 | ||||
-rw-r--r-- | doc/man5/x509v3_config.pod | 539 |
2 files changed, 923 insertions, 0 deletions
diff --git a/doc/man5/config.pod b/doc/man5/config.pod new file mode 100644 index 0000000000..9df0ecb1e4 --- /dev/null +++ b/doc/man5/config.pod @@ -0,0 +1,384 @@ +=pod + +=head1 NAME + +config - OpenSSL CONF library configuration files + +=head1 DESCRIPTION + +The OpenSSL CONF library can be used to read configuration files. +It is used for the OpenSSL master configuration file B<openssl.cnf> +and in a few other places like B<SPKAC> files and certificate extension +files for the B<x509> utility. OpenSSL applications can also use the +CONF library for their own purposes. + +A configuration file is divided into a number of sections. Each section +starts with a line B<[ section_name ]> and ends when a new section is +started or end of file is reached. A section name can consist of +alphanumeric characters and underscores. + +The first section of a configuration file is special and is referred +to as the B<default> section this is usually unnamed and is from the +start of file until the first named section. When a name is being looked up +it is first looked up in a named section (if any) and then the +default section. + +The environment is mapped onto a section called B<ENV>. + +Comments can be included by preceding them with the B<#> character + +Each section in a configuration file consists of a number of name and +value pairs of the form B<name=value> + +The B<name> string can contain any alphanumeric characters as well as +a few punctuation symbols such as B<.> B<,> B<;> and B<_>. + +The B<value> string consists of the string following the B<=> character +until end of line with any leading and trailing white space removed. + +The value string undergoes variable expansion. This can be done by +including the form B<$var> or B<${var}>: this will substitute the value +of the named variable in the current section. It is also possible to +substitute a value from another section using the syntax B<$section::name> +or B<${section::name}>. By using the form B<$ENV::name> environment +variables can be substituted. It is also possible to assign values to +environment variables by using the name B<ENV::name>, this will work +if the program looks up environment variables using the B<CONF> library +instead of calling getenv() directly. + +It is possible to escape certain characters by using any kind of quote +or the B<\> character. By making the last character of a line a B<\> +a B<value> string can be spread across multiple lines. In addition +the sequences B<\n>, B<\r>, B<\b> and B<\t> are recognized. + +=head1 OPENSSL LIBRARY CONFIGURATION + +Applications can automatically configure certain +aspects of OpenSSL using the master OpenSSL configuration file, or optionally +an alternative configuration file. The B<openssl> utility includes this +functionality: any sub command uses the master OpenSSL configuration file +unless an option is used in the sub command to use an alternative configuration +file. + +To enable library configuration the default section needs to contain an +appropriate line which points to the main configuration section. The default +name is B<openssl_conf> which is used by the B<openssl> utility. Other +applications may use an alternative name such as B<myapplicaton_conf>. + +The configuration section should consist of a set of name value pairs which +contain specific module configuration information. The B<name> represents +the name of the I<configuration module> the meaning of the B<value> is +module specific: it may, for example, represent a further configuration +section containing configuration module specific information. E.g. + + openssl_conf = openssl_init + + [openssl_init] + + oid_section = new_oids + engines = engine_section + + [new_oids] + + ... new oids here ... + + [engine_section] + + ... engine stuff here ... + +The features of each configuration module are described below. + +=head2 ASN1 Object Configuration Module + +This module has the name B<oid_section>. The value of this variable points +to a section containing name value pairs of OIDs: the name is the OID short +and long name, the value is the numerical form of the OID. Although some of +the B<openssl> utility sub commands already have their own ASN1 OBJECT section +functionality not all do. By using the ASN1 OBJECT configuration module +B<all> the B<openssl> utility sub commands can see the new objects as well +as any compliant applications. For example: + + [new_oids] + + some_new_oid = 1.2.3.4 + some_other_oid = 1.2.3.5 + +It is also possible to set the value to the long name followed +by a comma and the numerical OID form. For example: + + shortName = some object long name, 1.2.3.4 + +=head2 Engine Configuration Module + +This ENGINE configuration module has the name B<engines>. The value of this +variable points to a section containing further ENGINE configuration +information. + +The section pointed to by B<engines> is a table of engine names (though see +B<engine_id> below) and further sections containing configuration information +specific to each ENGINE. + +Each ENGINE specific section is used to set default algorithms, load +dynamic, perform initialization and send ctrls. The actual operation performed +depends on the I<command> name which is the name of the name value pair. The +currently supported commands are listed below. + +For example: + + [engine_section] + + # Configure ENGINE named "foo" + foo = foo_section + # Configure ENGINE named "bar" + bar = bar_section + + [foo_section] + ... foo ENGINE specific commands ... + + [bar_section] + ... "bar" ENGINE specific commands ... + +The command B<engine_id> is used to give the ENGINE name. If used this +command must be first. For example: + + [engine_section] + # This would normally handle an ENGINE named "foo" + foo = foo_section + + [foo_section] + # Override default name and use "myfoo" instead. + engine_id = myfoo + +The command B<dynamic_path> loads and adds an ENGINE from the given path. It +is equivalent to sending the ctrls B<SO_PATH> with the path argument followed +by B<LIST_ADD> with value 2 and B<LOAD> to the dynamic ENGINE. If this is +not the required behaviour then alternative ctrls can be sent directly +to the dynamic ENGINE using ctrl commands. + +The command B<init> determines whether to initialize the ENGINE. If the value +is B<0> the ENGINE will not be initialized, if B<1> and attempt it made to +initialized the ENGINE immediately. If the B<init> command is not present +then an attempt will be made to initialize the ENGINE after all commands in +its section have been processed. + +The command B<default_algorithms> sets the default algorithms an ENGINE will +supply using the functions ENGINE_set_default_string(). + +If the name matches none of the above command names it is assumed to be a +ctrl command which is sent to the ENGINE. The value of the command is the +argument to the ctrl command. If the value is the string B<EMPTY> then no +value is sent to the command. + +For example: + + + [engine_section] + + # Configure ENGINE named "foo" + foo = foo_section + + [foo_section] + # Load engine from DSO + dynamic_path = /some/path/fooengine.so + # A foo specific ctrl. + some_ctrl = some_value + # Another ctrl that doesn't take a value. + other_ctrl = EMPTY + # Supply all default algorithms + default_algorithms = ALL + +=head2 EVP Configuration Module + +This modules has the name B<alg_section> which points to a section containing +algorithm commands. + +Currently the only algorithm command supported is B<fips_mode> whose +value should be a boolean string such as B<on> or B<off>. If the value is +B<on> this attempt to enter FIPS mode. If the call fails or the library is +not FIPS capable then an error occurs. + +For example: + + alg_section = evp_settings + + [evp_settings] + + fips_mode = on + +=head2 SSL Configuration Module + +This module has the name B<ssl_conf> which points to a section containing +SSL configurations. + +Each line in the SSL configuration section contains the name of the +configuration and the section containing it. + +Each configuration section consists of command value pairs for B<SSL_CONF>. +Each pair will be passed to a B<SSL_CTX> or B<SSL> structure if it calls +SSL_CTX_config() or SSL_config() with the appropriate configuration name. + +Note: any characters before an initial dot in the configuration section are +ignored so the same command can be used multiple times. + +For example: + + ssl_conf = ssl_sect + + [ssl_sect] + + server = server_section + + [server_section] + + RSA.Certificate = server-rsa.pem + ECDSA.Certificate = server-ecdsa.pem + Ciphers = ALL:!RC4 + +=head1 NOTES + +If a configuration file attempts to expand a variable that doesn't exist +then an error is flagged and the file will not load. This can happen +if an attempt is made to expand an environment variable that doesn't +exist. For example in a previous version of OpenSSL the default OpenSSL +master configuration file used the value of B<HOME> which may not be +defined on non Unix systems and would cause an error. + +This can be worked around by including a B<default> section to provide +a default value: then if the environment lookup fails the default value +will be used instead. For this to work properly the default value must +be defined earlier in the configuration file than the expansion. See +the B<EXAMPLES> section for an example of how to do this. + +If the same variable exists in the same section then all but the last +value will be silently ignored. In certain circumstances such as with +DNs the same field may occur multiple times. This is usually worked +around by ignoring any characters before an initial B<.> e.g. + + 1.OU="My first OU" + 2.OU="My Second OU" + +=head1 EXAMPLES + +Here is a sample configuration file using some of the features +mentioned above. + + # This is the default section. + + HOME=/temp + RANDFILE= ${ENV::HOME}/.rnd + configdir=$ENV::HOME/config + + [ section_one ] + + # We are now in section one. + + # Quotes permit leading and trailing whitespace + any = " any variable name " + + other = A string that can \ + cover several lines \ + by including \\ characters + + message = Hello World\n + + [ section_two ] + + greeting = $section_one::message + +This next example shows how to expand environment variables safely. + +Suppose you want a variable called B<tmpfile> to refer to a +temporary filename. The directory it is placed in can determined by +the B<TEMP> or B<TMP> environment variables but they may not be +set to any value at all. If you just include the environment variable +names and the variable doesn't exist then this will cause an error when +an attempt is made to load the configuration file. By making use of the +default section both values can be looked up with B<TEMP> taking +priority and B</tmp> used if neither is defined: + + TMP=/tmp + # The above value is used if TMP isn't in the environment + TEMP=$ENV::TMP + # The above value is used if TEMP isn't in the environment + tmpfile=${ENV::TEMP}/tmp.filename + +Simple OpenSSL library configuration example to enter FIPS mode: + + # Default appname: should match "appname" parameter (if any) + # supplied to CONF_modules_load_file et al. + openssl_conf = openssl_conf_section + + [openssl_conf_section] + # Configuration module list + alg_section = evp_sect + + [evp_sect] + # Set to "yes" to enter FIPS mode if supported + fips_mode = yes + +Note: in the above example you will get an error in non FIPS capable versions +of OpenSSL. + +More complex OpenSSL library configuration. Add OID and don't enter FIPS mode: + + # Default appname: should match "appname" parameter (if any) + # supplied to CONF_modules_load_file et al. + openssl_conf = openssl_conf_section + + [openssl_conf_section] + # Configuration module list + alg_section = evp_sect + oid_section = new_oids + + [evp_sect] + # This will have no effect as FIPS mode is off by default. + # Set to "yes" to enter FIPS mode, if supported + fips_mode = no + + [new_oids] + # New OID, just short name + newoid1 = 1.2.3.4.1 + # New OID shortname and long name + newoid2 = New OID 2 long name, 1.2.3.4.2 + +The above examples can be used with any application supporting library +configuration if "openssl_conf" is modified to match the appropriate "appname". + +For example if the second sample file above is saved to "example.cnf" then +the command line: + + OPENSSL_CONF=example.cnf openssl asn1parse -genstr OID:1.2.3.4.1 + +will output: + + 0:d=0 hl=2 l= 4 prim: OBJECT :newoid1 + +showing that the OID "newoid1" has been added as "1.2.3.4.1". + +=head1 BUGS + +Currently there is no way to include characters using the octal B<\nnn> +form. Strings are all null terminated so nulls cannot form part of +the value. + +The escaping isn't quite right: if you want to use sequences like B<\n> +you can't use any quote escaping on the same line. + +Files are loaded in a single pass. This means that an variable expansion +will only work if the variables referenced are defined earlier in the +file. + +=head1 SEE ALSO + +L<x509(1)>, L<req(1)>, L<ca(1)> + +=head1 COPYRIGHT + +Copyright 2000-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 diff --git a/doc/man5/x509v3_config.pod b/doc/man5/x509v3_config.pod new file mode 100644 index 0000000000..e78cf7d760 --- /dev/null +++ b/doc/man5/x509v3_config.pod @@ -0,0 +1,539 @@ +=pod + +=head1 NAME + +x509v3_config - X509 V3 certificate extension configuration format + +=head1 DESCRIPTION + +Several of the OpenSSL utilities can add extensions to a certificate or +certificate request based on the contents of a configuration file. + +Typically the application will contain an option to point to an extension +section. Each line of the extension section takes the form: + + extension_name=[critical,] extension_options + +If B<critical> is present then the extension will be critical. + +The format of B<extension_options> depends on the value of B<extension_name>. + +There are four main types of extension: I<string> extensions, I<multi-valued> +extensions, I<raw> and I<arbitrary> extensions. + +String extensions simply have a string which contains either the value itself +or how it is obtained. + +For example: + + nsComment="This is a Comment" + +Multi-valued extensions have a short form and a long form. The short form +is a list of names and values: + + basicConstraints=critical,CA:true,pathlen:1 + +The long form allows the values to be placed in a separate section: + + basicConstraints=critical,@bs_section + + [bs_section] + + CA=true + pathlen=1 + +Both forms are equivalent. + +The syntax of raw extensions is governed by the extension code: it can +for example contain data in multiple sections. The correct syntax to +use is defined by the extension code itself: check out the certificate +policies extension for an example. + +If an extension type is unsupported then the I<arbitrary> extension syntax +must be used, see the L<ARBITRARY EXTENSIONS|/"ARBITRARY EXTENSIONS"> section for more details. + +=head1 STANDARD EXTENSIONS + +The following sections describe each supported extension in detail. + +=head2 Basic Constraints. + +This is a multi valued extension which indicates whether a certificate is +a CA certificate. The first (mandatory) name is B<CA> followed by B<TRUE> or +B<FALSE>. If B<CA> is B<TRUE> then an optional B<pathlen> name followed by an +non-negative value can be included. + +For example: + + basicConstraints=CA:TRUE + + basicConstraints=CA:FALSE + + basicConstraints=critical,CA:TRUE, pathlen:0 + +A CA certificate B<must> include the basicConstraints value with the CA field +set to TRUE. An end user certificate must either set CA to FALSE or exclude the +extension entirely. Some software may require the inclusion of basicConstraints +with CA set to FALSE for end entity certificates. + +The pathlen parameter indicates the maximum number of CAs that can appear +below this one in a chain. So if you have a CA with a pathlen of zero it can +only be used to sign end user certificates and not further CAs. + + +=head2 Key Usage. + +Key usage is a multi valued extension consisting of a list of names of the +permitted key usages. + +The supported names are: digitalSignature, nonRepudiation, keyEncipherment, +dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly +and decipherOnly. + +Examples: + + keyUsage=digitalSignature, nonRepudiation + + keyUsage=critical, keyCertSign + + +=head2 Extended Key Usage. + +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 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 + 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=serverAuth,clientAuth + + +=head2 Subject Key Identifier. + +This is really a string extension and can take two possible values. Either +the word B<hash> which will automatically follow the guidelines in RFC3280 +or a hex string giving the extension value to include. The use of the hex +string is strongly discouraged. + +Example: + + subjectKeyIdentifier=hash + + +=head2 Authority Key Identifier. + +The authority key identifier extension permits two options. keyid and issuer: +both can take the optional value "always". + +If the keyid option is present an attempt is made to copy the subject key +identifier from the parent certificate. If the value "always" is present +then an error is returned if the option fails. + +The issuer option copies the issuer and serial number from the issuer +certificate. This will only be done if the keyid option fails or +is not included unless the "always" flag will always include the value. + +Example: + + authorityKeyIdentifier=keyid,issuer + + +=head2 Subject Alternative Name. + +The subject alternative name extension allows various literal values to be +included in the configuration file. These include B<email> (an email address) +B<URI> a uniform resource indicator, B<DNS> (a DNS domain name), B<RID> (a +registered ID: OBJECT IDENTIFIER), B<IP> (an IP address), B<dirName> +(a distinguished name) and otherName. + +The email option include a special 'copy' value. This will automatically +include and email addresses contained in the certificate subject name in +the extension. + +The IP address used in the B<IP> options can be in either IPv4 or IPv6 format. + +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 +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)> format. + +Examples: + + subjectAltName=email:copy,email:my@other.address,URI:http://my.url.here/ + subjectAltName=IP:192.168.7.1 + subjectAltName=IP:13::17 + subjectAltName=email:my@other.address,RID:1.2.3.4 + subjectAltName=otherName:1.2.3.4;UTF8:some other identifier + + subjectAltName=dirName:dir_sect + + [dir_sect] + C=UK + O=My Organization + OU=My Unit + CN=My Name + + +=head2 Issuer Alternative Name. + +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 +certificate (if possible). + +Example: + + issuserAltName = issuer:copy + + +=head2 Authority Info Access. + +The authority information access extension gives details about how to access +certain information relating to the CA. Its syntax is accessOID;location +where I<location> has the same syntax as subject alternative name (except +that email:copy is not supported). accessOID can be any valid OID but only +certain values are meaningful, for example OCSP and caIssuers. + +Example: + + authorityInfoAccess = OCSP;URI:http://ocsp.my.host/ + authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html + + +=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 +a section name containing all the distribution point fields. + +For a name:value pair a new DistributionPoint with the fullName field set to +the given value both the cRLissuer and reasons fields are omitted in this case. + +In the single option case the section indicated contains values for each +field. In this section: + +If the name is "fullname" the value field should contain the full name +of the distribution point in the same format as subject alternative name. + +If the name is "relativename" then the value field should contain a section +name whose contents represent a DN fragment to be placed in this field. + +The name "CRLIssuer" if present should contain a value for this field in +subject alternative name format. + +If the name is "reasons" the value field should consist of a comma +separated field containing the reasons. Valid reasons are: "keyCompromise", +"CACompromise", "affiliationChanged", "superseded", "cessationOfOperation", +"certificateHold", "privilegeWithdrawn" and "AACompromise". + + +Simple examples: + + crlDistributionPoints=URI:http://myhost.com/myca.crl + crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth.com/my.crl + +Full distribution point example: + + crlDistributionPoints=crldp1_section + + [crldp1_section] + + fullname=URI:http://myhost.com/myca.crl + CRLissuer=dirName:issuer_sect + reasons=keyCompromise, CACompromise + + [issuer_sect] + C=UK + O=Organisation + CN=Some Name + +=head2 Issuing Distribution Point + +This extension should only appear in CRLs. It is a multi valued extension +whose syntax is similar to the "section" pointed to by the CRL distribution +points extension with a few differences. + +The names "reasons" and "CRLissuer" are not recognized. + +The name "onlysomereasons" is accepted which sets this field. The value is +in the same format as the CRL distribution point "reasons" field. + +The names "onlyuser", "onlyCA", "onlyAA" and "indirectCRL" are also accepted +the values should be a boolean value (TRUE or FALSE) to indicate the value of +the corresponding field. + +Example: + + issuingDistributionPoint=critical, @idp_section + + [idp_section] + + fullname=URI:http://myhost.com/myca.crl + indirectCRL=TRUE + onlysomereasons=keyCompromise, CACompromise + + [issuer_sect] + C=UK + O=Organisation + CN=Some Name + + +=head2 Certificate Policies. + +This is a I<raw> extension. All the fields of this extension can be set by +using the appropriate syntax. + +If you follow the PKIX recommendations and just using one OID then you just +include the value of that OID. Multiple OIDs can be set separated by commas, +for example: + + certificatePolicies= 1.2.4.5, 1.1.3.4 + +If you wish to include qualifiers then the policy OID and qualifiers need to +be specified in a separate section: this is done by using the @section syntax +instead of a literal OID value. + +The section referred to must include the policy OID using the name +policyIdentifier, cPSuri qualifiers can be included using the syntax: + + CPS.nnn=value + +userNotice qualifiers can be set using the syntax: + + userNotice.nnn=@notice + +The value of the userNotice qualifier is specified in the relevant section. +This section can include explicitText, organization and noticeNumbers +options. explicitText and organization are text strings, noticeNumbers is a +comma separated list of numbers. The organization and noticeNumbers options +(if included) must BOTH be present. If you use the userNotice option with IE5 +then you need the 'ia5org' option at the top level to modify the encoding: +otherwise it will not be interpreted properly. + +Example: + + certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect + + [polsect] + + policyIdentifier = 1.3.5.8 + CPS.1="http://my.host.name/" + CPS.2="http://my.your.name/" + userNotice.1=@notice + + [notice] + + explicitText="Explicit Text Here" + organization="Organisation Name" + noticeNumbers=1,2,3,4 + +The B<ia5org> option changes the type of the I<organization> field. In RFC2459 +it can only be of type DisplayText. In RFC3280 IA5Strring is also permissible. +Some software (for example some versions of MSIE) may require ia5org. + +=head2 Policy Constraints + +This is a multi-valued extension which consisting of the names +B<requireExplicitPolicy> or B<inhibitPolicyMapping> and a non negative integer +value. At least one component must be present. + +Example: + + policyConstraints = requireExplicitPolicy:3 + + +=head2 Inhibit Any Policy + +This is a string extension whose value must be a non negative integer. + +Example: + + inhibitAnyPolicy = 2 + + +=head2 Name Constraints + +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 +subnet mask separated by a B</>. + +Examples: + + nameConstraints=permitted;IP:192.168.0.0/255.255.0.0 + + nameConstraints=permitted;email:.somedomain.com + + nameConstraints=excluded;email:.com + + +=head2 OCSP No Check + +The OCSP No Check extension is a string extension but its value is ignored. + +Example: + + 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 +obsolete. Their use in new applications is discouraged. + +=head2 Netscape String extensions. + +Netscape Comment (B<nsComment>) is a string extension containing a comment +which will be displayed when the certificate is viewed in some browsers. + +Example: + + nsComment = "Some Random Comment" + +Other supported extensions in this category are: B<nsBaseUrl>, +B<nsRevocationUrl>, B<nsCaRevocationUrl>, B<nsRenewalUrl>, B<nsCaPolicyUrl> +and B<nsSslServerName>. + + +=head2 Netscape Certificate Type + +This is a multi-valued extensions which consists of a list of flags to be +included. It was used to indicate the purposes for which a certificate could +be used. The basicConstraints, keyUsage and extended key usage extensions are +now used instead. + +Acceptable values for nsCertType are: B<client>, B<server>, B<email>, +B<objsign>, B<reserved>, B<sslCA>, B<emailCA>, B<objCA>. + + +=head1 ARBITRARY EXTENSIONS + +If an extension is not supported by the OpenSSL code then it must be encoded +using the arbitrary extension format. It is also possible to use the arbitrary +format for supported extensions. Extreme care should be taken to ensure that +the data is formatted correctly for the given extension type. + +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)>. +For example: + + 1.2.3.4=critical,ASN1:UTF8String:Some random data + + 1.2.3.4=ASN1:SEQUENCE:seq_sect + + [seq_sect] + + field1 = UTF8:field1 + field2 = UTF8:field2 + +It is also possible to use the word DER to include the raw encoded data in any +extension. + + 1.2.3.4=critical,DER:01:02:03:04 + 1.2.3.4=DER:01020304 + +The value following DER is a hex dump of the DER encoding of the extension +Any extension can be placed in this form to override the default behaviour. +For example: + + basicConstraints=critical,DER:00:01:02:03 + +=head1 WARNING + +There is no guarantee that a specific implementation will process a given +extension. It may therefore be sometimes possible to use certificates for +purposes prohibited by their extensions because a specific application does +not recognize or honour the values of the relevant extensions. + +The DER and ASN1 options should be used with caution. It is possible to create +totally invalid extensions if they are not used carefully. + + +=head1 NOTES + +If an extension is multi-value and a field value must contain a comma the long +form must be used otherwise the comma would be misinterpreted as a field +separator. For example: + + subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar + +will produce an error but the equivalent form: + + subjectAltName=@subject_alt_section + + [subject_alt_section] + subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar + +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: + + subjectAltName=@alt_section + + [alt_section] + + email=steve@here + email=steve@there + +will only recognize the last value. This can be worked around by using the form: + + [alt_section] + + email.1=steve@here + email.2=steve@there + +=head1 SEE ALSO + +L<req(1)>, L<ca(1)>, L<x509(1)>, +L<ASN1_generate_nconf(3)> + +=head1 COPYRIGHT + +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 |