x509v3_config.pod 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591
  1. =pod
  2. =head1 NAME
  3. x509v3_config - X509 V3 certificate extension configuration format
  4. =head1 DESCRIPTION
  5. Several OpenSSL commands can add extensions to a certificate or
  6. certificate request based on the contents of a configuration file
  7. and CLI options such as B<-addext>.
  8. The syntax of configuration files is described in L<config(5)>.
  9. The commands typically have an option to specify the name of the configuration
  10. file, and a section within that file; see the documentation of the
  11. individual command for details.
  12. This page uses B<extensions> as the name of the section, when needed
  13. in examples.
  14. Each entry in the extension section takes the form:
  15. name = [critical, ]value(s)
  16. If B<critical> is present then the extension will be marked as critical.
  17. If multiple entries are processed for the same extension name,
  18. later entries override earlier ones with the same name.
  19. The format of B<values> depends on the value of B<name>, many have a
  20. type-value pairing where the type and value are separated by a colon.
  21. There are four main types of extension:
  22. string
  23. multi-valued
  24. raw
  25. arbitrary
  26. Each is described in the following paragraphs.
  27. String extensions simply have a string which contains either the value itself
  28. or how it is obtained.
  29. Multi-valued extensions have a short form and a long form. The short form
  30. is a comma-separated list of names and values:
  31. basicConstraints = critical, CA:true, pathlen:1
  32. The long form allows the values to be placed in a separate section:
  33. [extensions]
  34. basicConstraints = critical, @basic_constraints
  35. [basic_constraints]
  36. CA = true
  37. pathlen = 1
  38. Both forms are equivalent.
  39. If an extension is multi-value and a field value must contain a comma the long
  40. form must be used otherwise the comma would be misinterpreted as a field
  41. separator. For example:
  42. subjectAltName = URI:ldap://somehost.com/CN=foo,OU=bar
  43. will produce an error but the equivalent form:
  44. [extensions]
  45. subjectAltName = @subject_alt_section
  46. [subject_alt_section]
  47. subjectAltName = URI:ldap://somehost.com/CN=foo,OU=bar
  48. is valid.
  49. OpenSSL does not support multiple occurrences of the same field within a
  50. section. In this example:
  51. [extensions]
  52. subjectAltName = @alt_section
  53. [alt_section]
  54. email = steve@example.com
  55. email = steve@example.org
  56. will only recognize the last value. To specify multiple values append a
  57. numeric identifier, as shown here:
  58. [extensions]
  59. subjectAltName = @alt_section
  60. [alt_section]
  61. email.1 = steve@example.com
  62. email.2 = steve@example.org
  63. The syntax of raw extensions is defined by the source code that parses
  64. the extension but should be documened.
  65. See L</Certificate Policies> for an example of a raw extension.
  66. If an extension type is unsupported, then the I<arbitrary> extension syntax
  67. must be used, see the L</ARBITRARY EXTENSIONS> section for more details.
  68. =head1 STANDARD EXTENSIONS
  69. The following sections describe the syntax of each supported extension.
  70. They do not define the semantics of the extension.
  71. =head2 Basic Constraints
  72. This is a multi-valued extension which indicates whether a certificate is
  73. a CA certificate. The first value is B<CA> followed by B<TRUE> or
  74. B<FALSE>. If B<CA> is B<TRUE> then an optional B<pathlen> name followed by a
  75. nonnegative value can be included.
  76. For example:
  77. basicConstraints = CA:TRUE
  78. basicConstraints = CA:FALSE
  79. basicConstraints = critical, CA:TRUE, pathlen:1
  80. A CA certificate I<must> include the B<basicConstraints> name with the B<CA>
  81. parameter set to B<TRUE>. An end-user certificate must either have B<CA:FALSE>
  82. or omit the extension entirely.
  83. The B<pathlen> parameter specifies the maximum number of CAs that can appear
  84. below this one in a chain. A B<pathlen> of zero means the CA cannot sign
  85. any sub-CA's, and can only sign end-entity certificates.
  86. =head2 Key Usage
  87. Key usage is a multi-valued extension consisting of a list of names of
  88. the permitted key usages. The defined values are: C<digitalSignature>,
  89. C<nonRepudiation>, C<keyEncipherment>, C<dataEncipherment>, C<keyAgreement>,
  90. C<keyCertSign>, C<cRLSign>, C<encipherOnly>, and C<decipherOnly>.
  91. Examples:
  92. keyUsage = digitalSignature, nonRepudiation
  93. keyUsage = critical, keyCertSign
  94. =head2 Extended Key Usage
  95. This extension consists of a list of values indicating purposes for which
  96. the certificate public key can be used for, Each value can be either a
  97. short text name or an OID.
  98. The following text names, and their intended meaning, are known:
  99. Value Meaning
  100. ----- -------
  101. serverAuth SSL/TLS Web Server Authentication
  102. clientAuth SSL/TLS Web Client Authentication
  103. codeSigning Code signing
  104. emailProtection E-mail Protection (S/MIME)
  105. timeStamping Trusted Timestamping
  106. OCSPSigning OCSP Signing
  107. ipsecIKE ipsec Internet Key Exchange
  108. msCodeInd Microsoft Individual Code Signing (authenticode)
  109. msCodeCom Microsoft Commercial Code Signing (authenticode)
  110. msCTLSign Microsoft Trust List Signing
  111. msEFS Microsoft Encrypted File System
  112. Examples:
  113. extendedKeyUsage = critical, codeSigning, 1.2.3.4
  114. extendedKeyUsage = serverAuth, clientAuth
  115. =head2 Subject Key Identifier
  116. The SKID extension specification has a value with three choices.
  117. If the value is the word B<none> then no SKID extension will be included.
  118. If the value is the word B<hash>, or by default for the B<x509>, B<req>, and
  119. B<ca> apps, the process specified in RFC 5280 section 4.2.1.2. (1) is followed:
  120. The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT
  121. STRING subjectPublicKey (excluding the tag, length, and number of unused bits).
  122. Otherwise, the value must be a hex string (possibly with C<:> separating bytes)
  123. to output directly, however, this is strongly discouraged.
  124. Example:
  125. subjectKeyIdentifier = hash
  126. =head2 Authority Key Identifier
  127. The AKID extension specification may have the value B<none>
  128. indicating that no AKID shall be included.
  129. Otherwise it may have the value B<keyid> or B<issuer>
  130. or both of them, separated by C<,>.
  131. Either or both can have the option B<always>,
  132. indicated by putting a colon C<:> between the value and this option.
  133. By default the B<x509>, B<req>, and B<ca> apps behave as if
  134. "none" was given for self-signed certificates and "keyid, issuer" otherwise.
  135. If B<keyid> is present, an attempt is made to compute the hash of the public key
  136. corresponding to the signing key in case the certificate is self-signed,
  137. or else to copy the subject key identifier (SKID) from the issuer certificate.
  138. If this fails and the option B<always> is present, an error is returned.
  139. If B<issuer> is present, and in addition it has the option B<always> specified
  140. or B<keyid> is not present,
  141. then the issuer DN and serial number are copied from the issuer certificate.
  142. Examples:
  143. authorityKeyIdentifier = keyid, issuer
  144. authorityKeyIdentifier = keyid, issuer:always
  145. =head2 Subject Alternative Name
  146. This is a multi-valued extension that supports several types of name
  147. identifier, including
  148. B<email> (an email address),
  149. B<URI> (a uniform resource indicator),
  150. B<DNS> (a DNS domain name),
  151. B<RID> (a registered ID: OBJECT IDENTIFIER),
  152. B<IP> (an IP address),
  153. B<dirName> (a distinguished name),
  154. and B<otherName>.
  155. The syntax of each is described in the following paragraphs.
  156. The B<email> option has a special C<copy> value, which will automatically
  157. include any email addresses contained in the certificate subject name in
  158. the extension.
  159. The IP address used in the B<IP> option can be in either IPv4 or IPv6 format.
  160. The value of B<dirName> is specifies the configuration section containing
  161. the distinguished name to use, as a set of name-value pairs.
  162. Multi-valued AVAs can be formed by prefacing the name with a B<+> character.
  163. The value of B<otherName> can include arbitrary data associated with an OID;
  164. the value should be the OID followed by a semicolon and the content in specified
  165. using the syntax in L<ASN1_generate_nconf(3)>.
  166. Examples:
  167. subjectAltName = email:copy, email:my@example.com, URI:http://my.example.com/
  168. subjectAltName = IP:192.168.7.1
  169. subjectAltName = IP:13::17
  170. subjectAltName = email:my@example.com, RID:1.2.3.4
  171. subjectAltName = otherName:1.2.3.4;UTF8:some other identifier
  172. [extensions]
  173. subjectAltName = dirName:dir_sect
  174. [dir_sect]
  175. C = UK
  176. O = My Organization
  177. OU = My Unit
  178. CN = My Name
  179. Non-ASCII Email Address conforming the syntax defined in Section 3.3 of RFC 6531
  180. are provided as otherName.SmtpUTF8Mailbox. According to RFC 8398, the email
  181. address should be provided as UTF8String. To enforce the valid representation in
  182. the certificate, the SmtpUTF8Mailbox should be provided as follows
  183. subjectAltName=@alts
  184. [alts]
  185. otherName = 1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8String:nonasciiname.example.com
  186. =head2 Issuer Alternative Name
  187. This extension supports most of the options of subject alternative name;
  188. it does not support B<email:copy>.
  189. It also adds B<issuer:copy> as an allowed value, which copies any subject
  190. alternative names from the issuer certificate, if possible.
  191. Example:
  192. issuerAltName = issuer:copy
  193. =head2 Authority Info Access
  194. This extension gives details about how to retrieve information that
  195. related to the certificate that the CA makes available. The syntax is
  196. B<access_id;location>, where B<access_id> is an object identifier
  197. (although only a few values are well-known) and B<location> has the same
  198. syntax as subject alternative name (except that B<email:copy> is not supported).
  199. Possible values for access_id include B<OCSP> (OCSP responder),
  200. B<caIssuers> (CA Issuers),
  201. B<ad_timestamping> (AD Time Stamping),
  202. B<AD_DVCS> (ad dvcs),
  203. B<caRepository> (CA Repository).
  204. Examples:
  205. authorityInfoAccess = OCSP;URI:http://ocsp.example.com/,caIssuers;URI:http://myca.example.com/ca.cer
  206. authorityInfoAccess = OCSP;URI:http://ocsp.example.com/
  207. =head2 CRL distribution points
  208. This is a multi-valued extension whose values can be either a name-value
  209. pair using the same form as subject alternative name or a single value
  210. specifying the section name containing all the distribution point values.
  211. When a name-value pair is used, a DistributionPoint extension will
  212. be set with the given value as the fullName field as the distributionPoint
  213. value, and the reasons and cRLIssuer fields will be omitted.
  214. When a single option is used, the value specifies the section, and that
  215. section can have the following items:
  216. =over 4
  217. =item fullname
  218. The full name of the distribution point, in the same format as the subject
  219. alternative name.
  220. =item relativename
  221. The value is taken as a distinguished name fragment that is set as the
  222. value of the nameRelativeToCRLIssuer field.
  223. =item CRLIssuer
  224. The value must in the same format as the subject alternative name.
  225. =item reasons
  226. A multi-value field that contains the reasons for revocation. The recognized
  227. values are: C<keyCompromise>, C<CACompromise>, C<affiliationChanged>,
  228. C<superseded>, C<cessationOfOperation>, C<certificateHold>,
  229. C<privilegeWithdrawn>, and C<AACompromise>.
  230. =back
  231. Only one of B<fullname> or B<relativename> should be specified.
  232. Simple examples:
  233. crlDistributionPoints = URI:http://example.com/myca.crl
  234. crlDistributionPoints = URI:http://example.com/myca.crl, URI:http://example.org/my.crl
  235. Full distribution point example:
  236. [extensions]
  237. crlDistributionPoints = crldp1_section
  238. [crldp1_section]
  239. fullname = URI:http://example.com/myca.crl
  240. CRLissuer = dirName:issuer_sect
  241. reasons = keyCompromise, CACompromise
  242. [issuer_sect]
  243. C = UK
  244. O = Organisation
  245. CN = Some Name
  246. =head2 Issuing Distribution Point
  247. This extension should only appear in CRLs. It is a multi-valued extension
  248. whose syntax is similar to the "section" pointed to by the CRL distribution
  249. points extension. The following names have meaning:
  250. =over 4
  251. =item fullname
  252. The full name of the distribution point, in the same format as the subject
  253. alternative name.
  254. =item relativename
  255. The value is taken as a distinguished name fragment that is set as the
  256. value of the nameRelativeToCRLIssuer field.
  257. =item onlysomereasons
  258. A multi-value field that contains the reasons for revocation. The recognized
  259. values are: C<keyCompromise>, C<CACompromise>, C<affiliationChanged>,
  260. C<superseded>, C<cessationOfOperation>, C<certificateHold>,
  261. C<privilegeWithdrawn>, and C<AACompromise>.
  262. =item onlyuser, onlyCA, onlyAA, indirectCRL
  263. The value for each of these names is a boolean.
  264. =back
  265. Example:
  266. [extensions]
  267. issuingDistributionPoint = critical, @idp_section
  268. [idp_section]
  269. fullname = URI:http://example.com/myca.crl
  270. indirectCRL = TRUE
  271. onlysomereasons = keyCompromise, CACompromise
  272. =head2 Certificate Policies
  273. This is a I<raw> extension that supports all of the defined fields of the
  274. certificate extension.
  275. Policies without qualifiers are specified by giving the OID.
  276. Multiple policies are comma-separated. For example:
  277. certificatePolicies = 1.2.4.5, 1.1.3.4
  278. To include policy qualifiers, use the "@section" syntax to point to a
  279. section that specifies all the information.
  280. The section referred to must include the policy OID using the name
  281. B<policyIdentifier>. cPSuri qualifiers can be included using the syntax:
  282. CPS.nnn = value
  283. where C<nnn> is a number.
  284. userNotice qualifiers can be set using the syntax:
  285. userNotice.nnn = @notice
  286. The value of the userNotice qualifier is specified in the relevant section.
  287. This section can include B<explicitText>, B<organization>, and B<noticeNumbers>
  288. options. explicitText and organization are text strings, noticeNumbers is a
  289. comma separated list of numbers. The organization and noticeNumbers options
  290. (if included) must BOTH be present. Some software might require
  291. the B<ia5org> option at the top level; this changes the encoding from
  292. Displaytext to IA5String.
  293. Example:
  294. [extensions]
  295. certificatePolicies = ia5org, 1.2.3.4, 1.5.6.7.8, @polsect
  296. [polsect]
  297. policyIdentifier = 1.3.5.8
  298. CPS.1 = "http://my.host.example.com/"
  299. CPS.2 = "http://my.your.example.com/"
  300. userNotice.1 = @notice
  301. [notice]
  302. explicitText = "Explicit Text Here"
  303. organization = "Organisation Name"
  304. noticeNumbers = 1, 2, 3, 4
  305. The character encoding of explicitText can be specified by prefixing the
  306. value with B<UTF8>, B<BMP>, or B<VISIBLE> followed by colon. For example:
  307. [notice]
  308. explicitText = "UTF8:Explicit Text Here"
  309. =head2 Policy Constraints
  310. This is a multi-valued extension which consisting of the names
  311. B<requireExplicitPolicy> or B<inhibitPolicyMapping> and a non negative integer
  312. value. At least one component must be present.
  313. Example:
  314. policyConstraints = requireExplicitPolicy:3
  315. =head2 Inhibit Any Policy
  316. This is a string extension whose value must be a non negative integer.
  317. Example:
  318. inhibitAnyPolicy = 2
  319. =head2 Name Constraints
  320. This is a multi-valued extension. The name should
  321. begin with the word B<permitted> or B<excluded> followed by a B<;>. The rest of
  322. the name and the value follows the syntax of subjectAltName except
  323. B<email:copy>
  324. is not supported and the B<IP> form should consist of an IP addresses and
  325. subnet mask separated by a B</>.
  326. Examples:
  327. nameConstraints = permitted;IP:192.168.0.0/255.255.0.0
  328. nameConstraints = permitted;email:.example.com
  329. nameConstraints = excluded;email:.com
  330. =head2 OCSP No Check
  331. This is a string extension. It is parsed, but ignored.
  332. Example:
  333. noCheck = ignored
  334. =head2 TLS Feature (aka Must Staple)
  335. This is a multi-valued extension consisting of a list of TLS extension
  336. identifiers. Each identifier may be a number (0..65535) or a supported name.
  337. When a TLS client sends a listed extension, the TLS server is expected to
  338. include that extension in its reply.
  339. The supported names are: B<status_request> and B<status_request_v2>.
  340. Example:
  341. tlsfeature = status_request
  342. =head1 DEPRECATED EXTENSIONS
  343. The following extensions are non standard, Netscape specific and largely
  344. obsolete. Their use in new applications is discouraged.
  345. =head2 Netscape String extensions
  346. Netscape Comment (B<nsComment>) is a string extension containing a comment
  347. which will be displayed when the certificate is viewed in some browsers.
  348. Other extensions of this type are: B<nsBaseUrl>,
  349. B<nsRevocationUrl>, B<nsCaRevocationUrl>, B<nsRenewalUrl>, B<nsCaPolicyUrl>
  350. and B<nsSslServerName>.
  351. =head2 Netscape Certificate Type
  352. This is a multi-valued extensions which consists of a list of flags to be
  353. included. It was used to indicate the purposes for which a certificate could
  354. be used. The basicConstraints, keyUsage and extended key usage extensions are
  355. now used instead.
  356. Acceptable values for nsCertType are: B<client>, B<server>, B<email>,
  357. B<objsign>, B<reserved>, B<sslCA>, B<emailCA>, B<objCA>.
  358. =head1 ARBITRARY EXTENSIONS
  359. If an extension is not supported by the OpenSSL code then it must be encoded
  360. using the arbitrary extension format. It is also possible to use the arbitrary
  361. format for supported extensions. Extreme care should be taken to ensure that
  362. the data is formatted correctly for the given extension type.
  363. There are two ways to encode arbitrary extensions.
  364. The first way is to use the word ASN1 followed by the extension content
  365. using the same syntax as L<ASN1_generate_nconf(3)>.
  366. For example:
  367. [extensions]
  368. 1.2.3.4 = critical, ASN1:UTF8String:Some random data
  369. 1.2.3.4.1 = ASN1:SEQUENCE:seq_sect
  370. [seq_sect]
  371. field1 = UTF8:field1
  372. field2 = UTF8:field2
  373. It is also possible to use the word DER to include the raw encoded data in any
  374. extension.
  375. 1.2.3.4 = critical, DER:01:02:03:04
  376. 1.2.3.4.1 = DER:01020304
  377. The value following DER is a hex dump of the DER encoding of the extension
  378. Any extension can be placed in this form to override the default behaviour.
  379. For example:
  380. basicConstraints = critical, DER:00:01:02:03
  381. =head1 WARNINGS
  382. There is no guarantee that a specific implementation will process a given
  383. extension. It may therefore be sometimes possible to use certificates for
  384. purposes prohibited by their extensions because a specific application does
  385. not recognize or honour the values of the relevant extensions.
  386. The DER and ASN1 options should be used with caution. It is possible to create
  387. invalid extensions if they are not used carefully.
  388. =head1 SEE ALSO
  389. L<openssl-req(1)>, L<openssl-ca(1)>, L<openssl-x509(1)>,
  390. L<ASN1_generate_nconf(3)>
  391. =head1 COPYRIGHT
  392. Copyright 2004-2021 The OpenSSL Project Authors. All Rights Reserved.
  393. Licensed under the Apache License 2.0 (the "License"). You may not use
  394. this file except in compliance with the License. You can obtain a copy
  395. in the file LICENSE in the source distribution or at
  396. L<https://www.openssl.org/source/license.html>.
  397. =cut