ca.pod 22 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692
  1. =pod
  2. =head1 NAME
  3. ca - sample minimal CA application
  4. =head1 SYNOPSIS
  5. B<openssl> B<ca>
  6. [B<-verbose>]
  7. [B<-config filename>]
  8. [B<-name section>]
  9. [B<-gencrl>]
  10. [B<-revoke file>]
  11. [B<-status serial>]
  12. [B<-updatedb>]
  13. [B<-crl_reason reason>]
  14. [B<-crl_hold instruction>]
  15. [B<-crl_compromise time>]
  16. [B<-crl_CA_compromise time>]
  17. [B<-crldays days>]
  18. [B<-crlhours hours>]
  19. [B<-crlexts section>]
  20. [B<-startdate date>]
  21. [B<-enddate date>]
  22. [B<-days arg>]
  23. [B<-md arg>]
  24. [B<-policy arg>]
  25. [B<-keyfile arg>]
  26. [B<-keyform PEM|DER>]
  27. [B<-key arg>]
  28. [B<-passin arg>]
  29. [B<-cert file>]
  30. [B<-selfsign>]
  31. [B<-in file>]
  32. [B<-out file>]
  33. [B<-notext>]
  34. [B<-outdir dir>]
  35. [B<-infiles>]
  36. [B<-spkac file>]
  37. [B<-ss_cert file>]
  38. [B<-preserveDN>]
  39. [B<-noemailDN>]
  40. [B<-batch>]
  41. [B<-msie_hack>]
  42. [B<-extensions section>]
  43. [B<-extfile section>]
  44. [B<-engine id>]
  45. [B<-subj arg>]
  46. [B<-utf8>]
  47. [B<-multivalue-rdn>]
  48. =head1 DESCRIPTION
  49. The B<ca> command is a minimal CA application. It can be used
  50. to sign certificate requests in a variety of forms and generate
  51. CRLs it also maintains a text database of issued certificates
  52. and their status.
  53. The options descriptions will be divided into each purpose.
  54. =head1 CA OPTIONS
  55. =over 4
  56. =item B<-config filename>
  57. specifies the configuration file to use.
  58. =item B<-name section>
  59. specifies the configuration file section to use (overrides
  60. B<default_ca> in the B<ca> section).
  61. =item B<-in filename>
  62. an input filename containing a single certificate request to be
  63. signed by the CA.
  64. =item B<-ss_cert filename>
  65. a single self signed certificate to be signed by the CA.
  66. =item B<-spkac filename>
  67. a file containing a single Netscape signed public key and challenge
  68. and additional field values to be signed by the CA. See the B<SPKAC FORMAT>
  69. section for information on the required input and output format.
  70. =item B<-infiles>
  71. if present this should be the last option, all subsequent arguments
  72. are assumed to the the names of files containing certificate requests.
  73. =item B<-out filename>
  74. the output file to output certificates to. The default is standard
  75. output. The certificate details will also be printed out to this
  76. file in PEM format (except that B<-spkac> outputs DER format).
  77. =item B<-outdir directory>
  78. the directory to output certificates to. The certificate will be
  79. written to a filename consisting of the serial number in hex with
  80. ".pem" appended.
  81. =item B<-cert>
  82. the CA certificate file.
  83. =item B<-keyfile filename>
  84. the private key to sign requests with.
  85. =item B<-keyform PEM|DER>
  86. the format of the data in the private key file.
  87. The default is PEM.
  88. =item B<-key password>
  89. the password used to encrypt the private key. Since on some
  90. systems the command line arguments are visible (e.g. Unix with
  91. the 'ps' utility) this option should be used with caution.
  92. =item B<-selfsign>
  93. indicates the issued certificates are to be signed with the key
  94. the certificate requests were signed with (given with B<-keyfile>).
  95. Cerificate requests signed with a different key are ignored. If
  96. B<-spkac>, B<-ss_cert> or B<-gencrl> are given, B<-selfsign> is
  97. ignored.
  98. A consequence of using B<-selfsign> is that the self-signed
  99. certificate appears among the entries in the certificate database
  100. (see the configuration option B<database>), and uses the same
  101. serial number counter as all other certificates sign with the
  102. self-signed certificate.
  103. =item B<-passin arg>
  104. the key password source. For more information about the format of B<arg>
  105. see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
  106. =item B<-verbose>
  107. this prints extra details about the operations being performed.
  108. =item B<-notext>
  109. don't output the text form of a certificate to the output file.
  110. =item B<-startdate date>
  111. this allows the start date to be explicitly set. The format of the
  112. date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).
  113. =item B<-enddate date>
  114. this allows the expiry date to be explicitly set. The format of the
  115. date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).
  116. =item B<-days arg>
  117. the number of days to certify the certificate for.
  118. =item B<-md alg>
  119. the message digest to use. Possible values include md5, sha1 and mdc2.
  120. This option also applies to CRLs.
  121. =item B<-policy arg>
  122. this option defines the CA "policy" to use. This is a section in
  123. the configuration file which decides which fields should be mandatory
  124. or match the CA certificate. Check out the B<POLICY FORMAT> section
  125. for more information.
  126. =item B<-msie_hack>
  127. this is a legacy option to make B<ca> work with very old versions of
  128. the IE certificate enrollment control "certenr3". It used UniversalStrings
  129. for almost everything. Since the old control has various security bugs
  130. its use is strongly discouraged. The newer control "Xenroll" does not
  131. need this option.
  132. =item B<-preserveDN>
  133. Normally the DN order of a certificate is the same as the order of the
  134. fields in the relevant policy section. When this option is set the order
  135. is the same as the request. This is largely for compatibility with the
  136. older IE enrollment control which would only accept certificates if their
  137. DNs match the order of the request. This is not needed for Xenroll.
  138. =item B<-noemailDN>
  139. The DN of a certificate can contain the EMAIL field if present in the
  140. request DN, however it is good policy just having the e-mail set into
  141. the altName extension of the certificate. When this option is set the
  142. EMAIL field is removed from the certificate' subject and set only in
  143. the, eventually present, extensions. The B<email_in_dn> keyword can be
  144. used in the configuration file to enable this behaviour.
  145. =item B<-batch>
  146. this sets the batch mode. In this mode no questions will be asked
  147. and all certificates will be certified automatically.
  148. =item B<-extensions section>
  149. the section of the configuration file containing certificate extensions
  150. to be added when a certificate is issued (defaults to B<x509_extensions>
  151. unless the B<-extfile> option is used). If no extension section is
  152. present then, a V1 certificate is created. If the extension section
  153. is present (even if it is empty), then a V3 certificate is created.
  154. =item B<-extfile file>
  155. an additional configuration file to read certificate extensions from
  156. (using the default section unless the B<-extensions> option is also
  157. used).
  158. =item B<-engine id>
  159. specifying an engine (by it's unique B<id> string) will cause B<req>
  160. to attempt to obtain a functional reference to the specified engine,
  161. thus initialising it if needed. The engine will then be set as the default
  162. for all available algorithms.
  163. =item B<-subj arg>
  164. supersedes subject name given in the request.
  165. The arg must be formatted as I</type0=value0/type1=value1/type2=...>,
  166. characters may be escaped by \ (backslash), no spaces are skipped.
  167. =item B<-utf8>
  168. this option causes field values to be interpreted as UTF8 strings, by
  169. default they are interpreted as ASCII. This means that the field
  170. values, whether prompted from a terminal or obtained from a
  171. configuration file, must be valid UTF8 strings.
  172. =item B<-multivalue-rdn>
  173. this option causes the -subj argument to be interpretedt with full
  174. support for multivalued RDNs. Example:
  175. I</DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe>
  176. If -multi-rdn is not used then the UID value is I<123456+CN=John Doe>.
  177. =back
  178. =head1 CRL OPTIONS
  179. =over 4
  180. =item B<-gencrl>
  181. this option generates a CRL based on information in the index file.
  182. =item B<-crldays num>
  183. the number of days before the next CRL is due. That is the days from
  184. now to place in the CRL nextUpdate field.
  185. =item B<-crlhours num>
  186. the number of hours before the next CRL is due.
  187. =item B<-revoke filename>
  188. a filename containing a certificate to revoke.
  189. =item B<-status serial>
  190. displays the revocation status of the certificate with the specified
  191. serial number and exits.
  192. =item B<-updatedb>
  193. Updates the database index to purge expired certificates.
  194. =item B<-crl_reason reason>
  195. revocation reason, where B<reason> is one of: B<unspecified>, B<keyCompromise>,
  196. B<CACompromise>, B<affiliationChanged>, B<superseded>, B<cessationOfOperation>,
  197. B<certificateHold> or B<removeFromCRL>. The matching of B<reason> is case
  198. insensitive. Setting any revocation reason will make the CRL v2.
  199. In practive B<removeFromCRL> is not particularly useful because it is only used
  200. in delta CRLs which are not currently implemented.
  201. =item B<-crl_hold instruction>
  202. This sets the CRL revocation reason code to B<certificateHold> and the hold
  203. instruction to B<instruction> which must be an OID. Although any OID can be
  204. used only B<holdInstructionNone> (the use of which is discouraged by RFC2459)
  205. B<holdInstructionCallIssuer> or B<holdInstructionReject> will normally be used.
  206. =item B<-crl_compromise time>
  207. This sets the revocation reason to B<keyCompromise> and the compromise time to
  208. B<time>. B<time> should be in GeneralizedTime format that is B<YYYYMMDDHHMMSSZ>.
  209. =item B<-crl_CA_compromise time>
  210. This is the same as B<crl_compromise> except the revocation reason is set to
  211. B<CACompromise>.
  212. =item B<-crlexts section>
  213. the section of the configuration file containing CRL extensions to
  214. include. If no CRL extension section is present then a V1 CRL is
  215. created, if the CRL extension section is present (even if it is
  216. empty) then a V2 CRL is created. The CRL extensions specified are
  217. CRL extensions and B<not> CRL entry extensions. It should be noted
  218. that some software (for example Netscape) can't handle V2 CRLs.
  219. =back
  220. =head1 CONFIGURATION FILE OPTIONS
  221. The section of the configuration file containing options for B<ca>
  222. is found as follows: If the B<-name> command line option is used,
  223. then it names the section to be used. Otherwise the section to
  224. be used must be named in the B<default_ca> option of the B<ca> section
  225. of the configuration file (or in the default section of the
  226. configuration file). Besides B<default_ca>, the following options are
  227. read directly from the B<ca> section:
  228. RANDFILE
  229. preserve
  230. msie_hack
  231. With the exception of B<RANDFILE>, this is probably a bug and may
  232. change in future releases.
  233. Many of the configuration file options are identical to command line
  234. options. Where the option is present in the configuration file
  235. and the command line the command line value is used. Where an
  236. option is described as mandatory then it must be present in
  237. the configuration file or the command line equivalent (if
  238. any) used.
  239. =over 4
  240. =item B<oid_file>
  241. This specifies a file containing additional B<OBJECT IDENTIFIERS>.
  242. Each line of the file should consist of the numerical form of the
  243. object identifier followed by white space then the short name followed
  244. by white space and finally the long name.
  245. =item B<oid_section>
  246. This specifies a section in the configuration file containing extra
  247. object identifiers. Each line should consist of the short name of the
  248. object identifier followed by B<=> and the numerical form. The short
  249. and long names are the same when this option is used.
  250. =item B<new_certs_dir>
  251. the same as the B<-outdir> command line option. It specifies
  252. the directory where new certificates will be placed. Mandatory.
  253. =item B<certificate>
  254. the same as B<-cert>. It gives the file containing the CA
  255. certificate. Mandatory.
  256. =item B<private_key>
  257. same as the B<-keyfile> option. The file containing the
  258. CA private key. Mandatory.
  259. =item B<RANDFILE>
  260. a file used to read and write random number seed information, or
  261. an EGD socket (see L<RAND_egd(3)|RAND_egd(3)>).
  262. =item B<default_days>
  263. the same as the B<-days> option. The number of days to certify
  264. a certificate for.
  265. =item B<default_startdate>
  266. the same as the B<-startdate> option. The start date to certify
  267. a certificate for. If not set the current time is used.
  268. =item B<default_enddate>
  269. the same as the B<-enddate> option. Either this option or
  270. B<default_days> (or the command line equivalents) must be
  271. present.
  272. =item B<default_crl_hours default_crl_days>
  273. the same as the B<-crlhours> and the B<-crldays> options. These
  274. will only be used if neither command line option is present. At
  275. least one of these must be present to generate a CRL.
  276. =item B<default_md>
  277. the same as the B<-md> option. The message digest to use. Mandatory.
  278. =item B<database>
  279. the text database file to use. Mandatory. This file must be present
  280. though initially it will be empty.
  281. =item B<unique_subject>
  282. if the value B<yes> is given, the valid certificate entries in the
  283. database must have unique subjects. if the value B<no> is given,
  284. several valid certificate entries may have the exact same subject.
  285. The default value is B<yes>, to be compatible with older (pre 0.9.8)
  286. versions of OpenSSL. However, to make CA certificate roll-over easier,
  287. it's recommended to use the value B<no>, especially if combined with
  288. the B<-selfsign> command line option.
  289. =item B<serial>
  290. a text file containing the next serial number to use in hex. Mandatory.
  291. This file must be present and contain a valid serial number.
  292. =item B<crlnumber>
  293. a text file containing the next CRL number to use in hex. The crl number
  294. will be inserted in the CRLs only if this file exists. If this file is
  295. present, it must contain a valid CRL number.
  296. =item B<x509_extensions>
  297. the same as B<-extensions>.
  298. =item B<crl_extensions>
  299. the same as B<-crlexts>.
  300. =item B<preserve>
  301. the same as B<-preserveDN>
  302. =item B<email_in_dn>
  303. the same as B<-noemailDN>. If you want the EMAIL field to be removed
  304. from the DN of the certificate simply set this to 'no'. If not present
  305. the default is to allow for the EMAIL filed in the certificate's DN.
  306. =item B<msie_hack>
  307. the same as B<-msie_hack>
  308. =item B<policy>
  309. the same as B<-policy>. Mandatory. See the B<POLICY FORMAT> section
  310. for more information.
  311. =item B<name_opt>, B<cert_opt>
  312. these options allow the format used to display the certificate details
  313. when asking the user to confirm signing. All the options supported by
  314. the B<x509> utilities B<-nameopt> and B<-certopt> switches can be used
  315. here, except the B<no_signame> and B<no_sigdump> are permanently set
  316. and cannot be disabled (this is because the certificate signature cannot
  317. be displayed because the certificate has not been signed at this point).
  318. For convenience the values B<ca_default> are accepted by both to produce
  319. a reasonable output.
  320. If neither option is present the format used in earlier versions of
  321. OpenSSL is used. Use of the old format is B<strongly> discouraged because
  322. it only displays fields mentioned in the B<policy> section, mishandles
  323. multicharacter string types and does not display extensions.
  324. =item B<copy_extensions>
  325. determines how extensions in certificate requests should be handled.
  326. If set to B<none> or this option is not present then extensions are
  327. ignored and not copied to the certificate. If set to B<copy> then any
  328. extensions present in the request that are not already present are copied
  329. to the certificate. If set to B<copyall> then all extensions in the
  330. request are copied to the certificate: if the extension is already present
  331. in the certificate it is deleted first. See the B<WARNINGS> section before
  332. using this option.
  333. The main use of this option is to allow a certificate request to supply
  334. values for certain extensions such as subjectAltName.
  335. =back
  336. =head1 POLICY FORMAT
  337. The policy section consists of a set of variables corresponding to
  338. certificate DN fields. If the value is "match" then the field value
  339. must match the same field in the CA certificate. If the value is
  340. "supplied" then it must be present. If the value is "optional" then
  341. it may be present. Any fields not mentioned in the policy section
  342. are silently deleted, unless the B<-preserveDN> option is set but
  343. this can be regarded more of a quirk than intended behaviour.
  344. =head1 SPKAC FORMAT
  345. The input to the B<-spkac> command line option is a Netscape
  346. signed public key and challenge. This will usually come from
  347. the B<KEYGEN> tag in an HTML form to create a new private key.
  348. It is however possible to create SPKACs using the B<spkac> utility.
  349. The file should contain the variable SPKAC set to the value of
  350. the SPKAC and also the required DN components as name value pairs.
  351. If you need to include the same component twice then it can be
  352. preceded by a number and a '.'.
  353. When processing SPKAC format, the output is DER if the B<-out>
  354. flag is used, but PEM format if sending to stdout or the B<-outdir>
  355. flag is used.
  356. =head1 EXAMPLES
  357. Note: these examples assume that the B<ca> directory structure is
  358. already set up and the relevant files already exist. This usually
  359. involves creating a CA certificate and private key with B<req>, a
  360. serial number file and an empty index file and placing them in
  361. the relevant directories.
  362. To use the sample configuration file below the directories demoCA,
  363. demoCA/private and demoCA/newcerts would be created. The CA
  364. certificate would be copied to demoCA/cacert.pem and its private
  365. key to demoCA/private/cakey.pem. A file demoCA/serial would be
  366. created containing for example "01" and the empty index file
  367. demoCA/index.txt.
  368. Sign a certificate request:
  369. openssl ca -in req.pem -out newcert.pem
  370. Sign a certificate request, using CA extensions:
  371. openssl ca -in req.pem -extensions v3_ca -out newcert.pem
  372. Generate a CRL
  373. openssl ca -gencrl -out crl.pem
  374. Sign several requests:
  375. openssl ca -infiles req1.pem req2.pem req3.pem
  376. Certify a Netscape SPKAC:
  377. openssl ca -spkac spkac.txt
  378. A sample SPKAC file (the SPKAC line has been truncated for clarity):
  379. SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5
  380. CN=Steve Test
  381. emailAddress=steve@openssl.org
  382. 0.OU=OpenSSL Group
  383. 1.OU=Another Group
  384. A sample configuration file with the relevant sections for B<ca>:
  385. [ ca ]
  386. default_ca = CA_default # The default ca section
  387. [ CA_default ]
  388. dir = ./demoCA # top dir
  389. database = $dir/index.txt # index file.
  390. new_certs_dir = $dir/newcerts # new certs dir
  391. certificate = $dir/cacert.pem # The CA cert
  392. serial = $dir/serial # serial no file
  393. private_key = $dir/private/cakey.pem# CA private key
  394. RANDFILE = $dir/private/.rand # random number file
  395. default_days = 365 # how long to certify for
  396. default_crl_days= 30 # how long before next CRL
  397. default_md = md5 # md to use
  398. policy = policy_any # default policy
  399. email_in_dn = no # Don't add the email into cert DN
  400. name_opt = ca_default # Subject name display option
  401. cert_opt = ca_default # Certificate display option
  402. copy_extensions = none # Don't copy extensions from request
  403. [ policy_any ]
  404. countryName = supplied
  405. stateOrProvinceName = optional
  406. organizationName = optional
  407. organizationalUnitName = optional
  408. commonName = supplied
  409. emailAddress = optional
  410. =head1 FILES
  411. Note: the location of all files can change either by compile time options,
  412. configuration file entries, environment variables or command line options.
  413. The values below reflect the default values.
  414. /usr/local/ssl/lib/openssl.cnf - master configuration file
  415. ./demoCA - main CA directory
  416. ./demoCA/cacert.pem - CA certificate
  417. ./demoCA/private/cakey.pem - CA private key
  418. ./demoCA/serial - CA serial number file
  419. ./demoCA/serial.old - CA serial number backup file
  420. ./demoCA/index.txt - CA text database file
  421. ./demoCA/index.txt.old - CA text database backup file
  422. ./demoCA/certs - certificate output file
  423. ./demoCA/.rnd - CA random seed information
  424. =head1 ENVIRONMENT VARIABLES
  425. B<OPENSSL_CONF> reflects the location of master configuration file it can
  426. be overridden by the B<-config> command line option.
  427. =head1 RESTRICTIONS
  428. The text database index file is a critical part of the process and
  429. if corrupted it can be difficult to fix. It is theoretically possible
  430. to rebuild the index file from all the issued certificates and a current
  431. CRL: however there is no option to do this.
  432. V2 CRL features like delta CRLs are not currently supported.
  433. Although several requests can be input and handled at once it is only
  434. possible to include one SPKAC or self signed certificate.
  435. =head1 BUGS
  436. The use of an in memory text database can cause problems when large
  437. numbers of certificates are present because, as the name implies
  438. the database has to be kept in memory.
  439. The B<ca> command really needs rewriting or the required functionality
  440. exposed at either a command or interface level so a more friendly utility
  441. (perl script or GUI) can handle things properly. The scripts B<CA.sh> and
  442. B<CA.pl> help a little but not very much.
  443. Any fields in a request that are not present in a policy are silently
  444. deleted. This does not happen if the B<-preserveDN> option is used. To
  445. enforce the absence of the EMAIL field within the DN, as suggested by
  446. RFCs, regardless the contents of the request' subject the B<-noemailDN>
  447. option can be used. The behaviour should be more friendly and
  448. configurable.
  449. Cancelling some commands by refusing to certify a certificate can
  450. create an empty file.
  451. =head1 WARNINGS
  452. The B<ca> command is quirky and at times downright unfriendly.
  453. The B<ca> utility was originally meant as an example of how to do things
  454. in a CA. It was not supposed to be used as a full blown CA itself:
  455. nevertheless some people are using it for this purpose.
  456. The B<ca> command is effectively a single user command: no locking is
  457. done on the various files and attempts to run more than one B<ca> command
  458. on the same database can have unpredictable results.
  459. The B<copy_extensions> option should be used with caution. If care is
  460. not taken then it can be a security risk. For example if a certificate
  461. request contains a basicConstraints extension with CA:TRUE and the
  462. B<copy_extensions> value is set to B<copyall> and the user does not spot
  463. this when the certificate is displayed then this will hand the requestor
  464. a valid CA certificate.
  465. This situation can be avoided by setting B<copy_extensions> to B<copy>
  466. and including basicConstraints with CA:FALSE in the configuration file.
  467. Then if the request contains a basicConstraints extension it will be
  468. ignored.
  469. It is advisable to also include values for other extensions such
  470. as B<keyUsage> to prevent a request supplying its own values.
  471. Additional restrictions can be placed on the CA certificate itself.
  472. For example if the CA certificate has:
  473. basicConstraints = CA:TRUE, pathlen:0
  474. then even if a certificate is issued with CA:TRUE it will not be valid.
  475. =head1 SEE ALSO
  476. L<req(1)|req(1)>, L<spkac(1)|spkac(1)>, L<x509(1)|x509(1)>, L<CA.pl(1)|CA.pl(1)>,
  477. L<config(5)|config(5)>
  478. =cut