xref: /onnv-gate/usr/src/common/openssl/doc/apps/smime.pod (revision 2175:b0b2f052a486)
1*2175Sjp161948=pod
2*2175Sjp161948
3*2175Sjp161948=head1 NAME
4*2175Sjp161948
5*2175Sjp161948smime - S/MIME utility
6*2175Sjp161948
7*2175Sjp161948=head1 SYNOPSIS
8*2175Sjp161948
9*2175Sjp161948B<openssl> B<smime>
10*2175Sjp161948[B<-encrypt>]
11*2175Sjp161948[B<-decrypt>]
12*2175Sjp161948[B<-sign>]
13*2175Sjp161948[B<-verify>]
14*2175Sjp161948[B<-pk7out>]
15*2175Sjp161948[B<-des>]
16*2175Sjp161948[B<-des3>]
17*2175Sjp161948[B<-rc2-40>]
18*2175Sjp161948[B<-rc2-64>]
19*2175Sjp161948[B<-rc2-128>]
20*2175Sjp161948[B<-aes128>]
21*2175Sjp161948[B<-aes192>]
22*2175Sjp161948[B<-aes256>]
23*2175Sjp161948[B<-in file>]
24*2175Sjp161948[B<-certfile file>]
25*2175Sjp161948[B<-signer file>]
26*2175Sjp161948[B<-recip  file>]
27*2175Sjp161948[B<-inform SMIME|PEM|DER>]
28*2175Sjp161948[B<-passin arg>]
29*2175Sjp161948[B<-inkey file>]
30*2175Sjp161948[B<-out file>]
31*2175Sjp161948[B<-outform SMIME|PEM|DER>]
32*2175Sjp161948[B<-content file>]
33*2175Sjp161948[B<-to addr>]
34*2175Sjp161948[B<-from ad>]
35*2175Sjp161948[B<-subject s>]
36*2175Sjp161948[B<-text>]
37*2175Sjp161948[B<-rand file(s)>]
38*2175Sjp161948[cert.pem]...
39*2175Sjp161948
40*2175Sjp161948=head1 DESCRIPTION
41*2175Sjp161948
42*2175Sjp161948The B<smime> command handles S/MIME mail. It can encrypt, decrypt, sign and
43*2175Sjp161948verify S/MIME messages.
44*2175Sjp161948
45*2175Sjp161948=head1 COMMAND OPTIONS
46*2175Sjp161948
47*2175Sjp161948There are five operation options that set the type of operation to be performed.
48*2175Sjp161948The meaning of the other options varies according to the operation type.
49*2175Sjp161948
50*2175Sjp161948=over 4
51*2175Sjp161948
52*2175Sjp161948=item B<-encrypt>
53*2175Sjp161948
54*2175Sjp161948encrypt mail for the given recipient certificates. Input file is the message
55*2175Sjp161948to be encrypted. The output file is the encrypted mail in MIME format.
56*2175Sjp161948
57*2175Sjp161948=item B<-decrypt>
58*2175Sjp161948
59*2175Sjp161948decrypt mail using the supplied certificate and private key. Expects an
60*2175Sjp161948encrypted mail message in MIME format for the input file. The decrypted mail
61*2175Sjp161948is written to the output file.
62*2175Sjp161948
63*2175Sjp161948=item B<-sign>
64*2175Sjp161948
65*2175Sjp161948sign mail using the supplied certificate and private key. Input file is
66*2175Sjp161948the message to be signed. The signed message in MIME format is written
67*2175Sjp161948to the output file.
68*2175Sjp161948
69*2175Sjp161948=item B<-verify>
70*2175Sjp161948
71*2175Sjp161948verify signed mail. Expects a signed mail message on input and outputs
72*2175Sjp161948the signed data. Both clear text and opaque signing is supported.
73*2175Sjp161948
74*2175Sjp161948=item B<-pk7out>
75*2175Sjp161948
76*2175Sjp161948takes an input message and writes out a PEM encoded PKCS#7 structure.
77*2175Sjp161948
78*2175Sjp161948=item B<-in filename>
79*2175Sjp161948
80*2175Sjp161948the input message to be encrypted or signed or the MIME message to
81*2175Sjp161948be decrypted or verified.
82*2175Sjp161948
83*2175Sjp161948=item B<-inform SMIME|PEM|DER>
84*2175Sjp161948
85*2175Sjp161948this specifies the input format for the PKCS#7 structure. The default
86*2175Sjp161948is B<SMIME> which reads an S/MIME format message. B<PEM> and B<DER>
87*2175Sjp161948format change this to expect PEM and DER format PKCS#7 structures
88*2175Sjp161948instead. This currently only affects the input format of the PKCS#7
89*2175Sjp161948structure, if no PKCS#7 structure is being input (for example with
90*2175Sjp161948B<-encrypt> or B<-sign>) this option has no effect.
91*2175Sjp161948
92*2175Sjp161948=item B<-out filename>
93*2175Sjp161948
94*2175Sjp161948the message text that has been decrypted or verified or the output MIME
95*2175Sjp161948format message that has been signed or verified.
96*2175Sjp161948
97*2175Sjp161948=item B<-outform SMIME|PEM|DER>
98*2175Sjp161948
99*2175Sjp161948this specifies the output format for the PKCS#7 structure. The default
100*2175Sjp161948is B<SMIME> which write an S/MIME format message. B<PEM> and B<DER>
101*2175Sjp161948format change this to write PEM and DER format PKCS#7 structures
102*2175Sjp161948instead. This currently only affects the output format of the PKCS#7
103*2175Sjp161948structure, if no PKCS#7 structure is being output (for example with
104*2175Sjp161948B<-verify> or B<-decrypt>) this option has no effect.
105*2175Sjp161948
106*2175Sjp161948=item B<-content filename>
107*2175Sjp161948
108*2175Sjp161948This specifies a file containing the detached content, this is only
109*2175Sjp161948useful with the B<-verify> command. This is only usable if the PKCS#7
110*2175Sjp161948structure is using the detached signature form where the content is
111*2175Sjp161948not included. This option will override any content if the input format
112*2175Sjp161948is S/MIME and it uses the multipart/signed MIME content type.
113*2175Sjp161948
114*2175Sjp161948=item B<-text>
115*2175Sjp161948
116*2175Sjp161948this option adds plain text (text/plain) MIME headers to the supplied
117*2175Sjp161948message if encrypting or signing. If decrypting or verifying it strips
118*2175Sjp161948off text headers: if the decrypted or verified message is not of MIME
119*2175Sjp161948type text/plain then an error occurs.
120*2175Sjp161948
121*2175Sjp161948=item B<-CAfile file>
122*2175Sjp161948
123*2175Sjp161948a file containing trusted CA certificates, only used with B<-verify>.
124*2175Sjp161948
125*2175Sjp161948=item B<-CApath dir>
126*2175Sjp161948
127*2175Sjp161948a directory containing trusted CA certificates, only used with
128*2175Sjp161948B<-verify>. This directory must be a standard certificate directory: that
129*2175Sjp161948is a hash of each subject name (using B<x509 -hash>) should be linked
130*2175Sjp161948to each certificate.
131*2175Sjp161948
132*2175Sjp161948=item B<-des -des3 -rc2-40 -rc2-64 -rc2-128 -aes128 -aes192 -aes256>
133*2175Sjp161948
134*2175Sjp161948the encryption algorithm to use. DES (56 bits), triple DES (168 bits),
135*2175Sjp16194840, 64 or 128 bit RC2 or 128, 192 or 256 bit AES respectively.  If not
136*2175Sjp161948specified 40 bit RC2 is used. Only used with B<-encrypt>.
137*2175Sjp161948
138*2175Sjp161948=item B<-nointern>
139*2175Sjp161948
140*2175Sjp161948when verifying a message normally certificates (if any) included in
141*2175Sjp161948the message are searched for the signing certificate. With this option
142*2175Sjp161948only the certificates specified in the B<-certfile> option are used.
143*2175Sjp161948The supplied certificates can still be used as untrusted CAs however.
144*2175Sjp161948
145*2175Sjp161948=item B<-noverify>
146*2175Sjp161948
147*2175Sjp161948do not verify the signers certificate of a signed message.
148*2175Sjp161948
149*2175Sjp161948=item B<-nochain>
150*2175Sjp161948
151*2175Sjp161948do not do chain verification of signers certificates: that is don't
152*2175Sjp161948use the certificates in the signed message as untrusted CAs.
153*2175Sjp161948
154*2175Sjp161948=item B<-nosigs>
155*2175Sjp161948
156*2175Sjp161948don't try to verify the signatures on the message.
157*2175Sjp161948
158*2175Sjp161948=item B<-nocerts>
159*2175Sjp161948
160*2175Sjp161948when signing a message the signer's certificate is normally included
161*2175Sjp161948with this option it is excluded. This will reduce the size of the
162*2175Sjp161948signed message but the verifier must have a copy of the signers certificate
163*2175Sjp161948available locally (passed using the B<-certfile> option for example).
164*2175Sjp161948
165*2175Sjp161948=item B<-noattr>
166*2175Sjp161948
167*2175Sjp161948normally when a message is signed a set of attributes are included which
168*2175Sjp161948include the signing time and supported symmetric algorithms. With this
169*2175Sjp161948option they are not included.
170*2175Sjp161948
171*2175Sjp161948=item B<-binary>
172*2175Sjp161948
173*2175Sjp161948normally the input message is converted to "canonical" format which is
174*2175Sjp161948effectively using CR and LF as end of line: as required by the S/MIME
175*2175Sjp161948specification. When this option is present no translation occurs. This
176*2175Sjp161948is useful when handling binary data which may not be in MIME format.
177*2175Sjp161948
178*2175Sjp161948=item B<-nodetach>
179*2175Sjp161948
180*2175Sjp161948when signing a message use opaque signing: this form is more resistant
181*2175Sjp161948to translation by mail relays but it cannot be read by mail agents that
182*2175Sjp161948do not support S/MIME.  Without this option cleartext signing with
183*2175Sjp161948the MIME type multipart/signed is used.
184*2175Sjp161948
185*2175Sjp161948=item B<-certfile file>
186*2175Sjp161948
187*2175Sjp161948allows additional certificates to be specified. When signing these will
188*2175Sjp161948be included with the message. When verifying these will be searched for
189*2175Sjp161948the signers certificates. The certificates should be in PEM format.
190*2175Sjp161948
191*2175Sjp161948=item B<-signer file>
192*2175Sjp161948
193*2175Sjp161948the signers certificate when signing a message. If a message is
194*2175Sjp161948being verified then the signers certificates will be written to this
195*2175Sjp161948file if the verification was successful.
196*2175Sjp161948
197*2175Sjp161948=item B<-recip file>
198*2175Sjp161948
199*2175Sjp161948the recipients certificate when decrypting a message. This certificate
200*2175Sjp161948must match one of the recipients of the message or an error occurs.
201*2175Sjp161948
202*2175Sjp161948=item B<-inkey file>
203*2175Sjp161948
204*2175Sjp161948the private key to use when signing or decrypting. This must match the
205*2175Sjp161948corresponding certificate. If this option is not specified then the
206*2175Sjp161948private key must be included in the certificate file specified with
207*2175Sjp161948the B<-recip> or B<-signer> file.
208*2175Sjp161948
209*2175Sjp161948=item B<-passin arg>
210*2175Sjp161948
211*2175Sjp161948the private key password source. For more information about the format of B<arg>
212*2175Sjp161948see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
213*2175Sjp161948
214*2175Sjp161948=item B<-rand file(s)>
215*2175Sjp161948
216*2175Sjp161948a file or files containing random data used to seed the random number
217*2175Sjp161948generator, or an EGD socket (see L<RAND_egd(3)|RAND_egd(3)>).
218*2175Sjp161948Multiple files can be specified separated by a OS-dependent character.
219*2175Sjp161948The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
220*2175Sjp161948all others.
221*2175Sjp161948
222*2175Sjp161948=item B<cert.pem...>
223*2175Sjp161948
224*2175Sjp161948one or more certificates of message recipients: used when encrypting
225*2175Sjp161948a message.
226*2175Sjp161948
227*2175Sjp161948=item B<-to, -from, -subject>
228*2175Sjp161948
229*2175Sjp161948the relevant mail headers. These are included outside the signed
230*2175Sjp161948portion of a message so they may be included manually. If signing
231*2175Sjp161948then many S/MIME mail clients check the signers certificate's email
232*2175Sjp161948address matches that specified in the From: address.
233*2175Sjp161948
234*2175Sjp161948=back
235*2175Sjp161948
236*2175Sjp161948=head1 NOTES
237*2175Sjp161948
238*2175Sjp161948The MIME message must be sent without any blank lines between the
239*2175Sjp161948headers and the output. Some mail programs will automatically add
240*2175Sjp161948a blank line. Piping the mail directly to sendmail is one way to
241*2175Sjp161948achieve the correct format.
242*2175Sjp161948
243*2175Sjp161948The supplied message to be signed or encrypted must include the
244*2175Sjp161948necessary MIME headers or many S/MIME clients wont display it
245*2175Sjp161948properly (if at all). You can use the B<-text> option to automatically
246*2175Sjp161948add plain text headers.
247*2175Sjp161948
248*2175Sjp161948A "signed and encrypted" message is one where a signed message is
249*2175Sjp161948then encrypted. This can be produced by encrypting an already signed
250*2175Sjp161948message: see the examples section.
251*2175Sjp161948
252*2175Sjp161948This version of the program only allows one signer per message but it
253*2175Sjp161948will verify multiple signers on received messages. Some S/MIME clients
254*2175Sjp161948choke if a message contains multiple signers. It is possible to sign
255*2175Sjp161948messages "in parallel" by signing an already signed message.
256*2175Sjp161948
257*2175Sjp161948The options B<-encrypt> and B<-decrypt> reflect common usage in S/MIME
258*2175Sjp161948clients. Strictly speaking these process PKCS#7 enveloped data: PKCS#7
259*2175Sjp161948encrypted data is used for other purposes.
260*2175Sjp161948
261*2175Sjp161948=head1 EXIT CODES
262*2175Sjp161948
263*2175Sjp161948=over 4
264*2175Sjp161948
265*2175Sjp161948=item 0
266*2175Sjp161948
267*2175Sjp161948the operation was completely successfully.
268*2175Sjp161948
269*2175Sjp161948=item 1
270*2175Sjp161948
271*2175Sjp161948an error occurred parsing the command options.
272*2175Sjp161948
273*2175Sjp161948=item 2
274*2175Sjp161948
275*2175Sjp161948one of the input files could not be read.
276*2175Sjp161948
277*2175Sjp161948=item 3
278*2175Sjp161948
279*2175Sjp161948an error occurred creating the PKCS#7 file or when reading the MIME
280*2175Sjp161948message.
281*2175Sjp161948
282*2175Sjp161948=item 4
283*2175Sjp161948
284*2175Sjp161948an error occurred decrypting or verifying the message.
285*2175Sjp161948
286*2175Sjp161948=item 5
287*2175Sjp161948
288*2175Sjp161948the message was verified correctly but an error occurred writing out
289*2175Sjp161948the signers certificates.
290*2175Sjp161948
291*2175Sjp161948=back
292*2175Sjp161948
293*2175Sjp161948=head1 EXAMPLES
294*2175Sjp161948
295*2175Sjp161948Create a cleartext signed message:
296*2175Sjp161948
297*2175Sjp161948 openssl smime -sign -in message.txt -text -out mail.msg \
298*2175Sjp161948	-signer mycert.pem
299*2175Sjp161948
300*2175Sjp161948Create and opaque signed message
301*2175Sjp161948
302*2175Sjp161948 openssl smime -sign -in message.txt -text -out mail.msg -nodetach \
303*2175Sjp161948	-signer mycert.pem
304*2175Sjp161948
305*2175Sjp161948Create a signed message, include some additional certificates and
306*2175Sjp161948read the private key from another file:
307*2175Sjp161948
308*2175Sjp161948 openssl smime -sign -in in.txt -text -out mail.msg \
309*2175Sjp161948	-signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
310*2175Sjp161948
311*2175Sjp161948Send a signed message under Unix directly to sendmail, including headers:
312*2175Sjp161948
313*2175Sjp161948 openssl smime -sign -in in.txt -text -signer mycert.pem \
314*2175Sjp161948	-from steve@openssl.org -to someone@somewhere \
315*2175Sjp161948	-subject "Signed message" | sendmail someone@somewhere
316*2175Sjp161948
317*2175Sjp161948Verify a message and extract the signer's certificate if successful:
318*2175Sjp161948
319*2175Sjp161948 openssl smime -verify -in mail.msg -signer user.pem -out signedtext.txt
320*2175Sjp161948
321*2175Sjp161948Send encrypted mail using triple DES:
322*2175Sjp161948
323*2175Sjp161948 openssl smime -encrypt -in in.txt -from steve@openssl.org \
324*2175Sjp161948	-to someone@somewhere -subject "Encrypted message" \
325*2175Sjp161948	-des3 user.pem -out mail.msg
326*2175Sjp161948
327*2175Sjp161948Sign and encrypt mail:
328*2175Sjp161948
329*2175Sjp161948 openssl smime -sign -in ml.txt -signer my.pem -text \
330*2175Sjp161948	| openssl smime -encrypt -out mail.msg \
331*2175Sjp161948	-from steve@openssl.org -to someone@somewhere \
332*2175Sjp161948	-subject "Signed and Encrypted message" -des3 user.pem
333*2175Sjp161948
334*2175Sjp161948Note: the encryption command does not include the B<-text> option because the message
335*2175Sjp161948being encrypted already has MIME headers.
336*2175Sjp161948
337*2175Sjp161948Decrypt mail:
338*2175Sjp161948
339*2175Sjp161948 openssl smime -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
340*2175Sjp161948
341*2175Sjp161948The output from Netscape form signing is a PKCS#7 structure with the
342*2175Sjp161948detached signature format. You can use this program to verify the
343*2175Sjp161948signature by line wrapping the base64 encoded structure and surrounding
344*2175Sjp161948it with:
345*2175Sjp161948
346*2175Sjp161948 -----BEGIN PKCS7-----
347*2175Sjp161948 -----END PKCS7-----
348*2175Sjp161948
349*2175Sjp161948and using the command,
350*2175Sjp161948
351*2175Sjp161948 openssl smime -verify -inform PEM -in signature.pem -content content.txt
352*2175Sjp161948
353*2175Sjp161948alternatively you can base64 decode the signature and use
354*2175Sjp161948
355*2175Sjp161948 openssl smime -verify -inform DER -in signature.der -content content.txt
356*2175Sjp161948
357*2175Sjp161948=head1 BUGS
358*2175Sjp161948
359*2175Sjp161948The MIME parser isn't very clever: it seems to handle most messages that I've thrown
360*2175Sjp161948at it but it may choke on others.
361*2175Sjp161948
362*2175Sjp161948The code currently will only write out the signer's certificate to a file: if the
363*2175Sjp161948signer has a separate encryption certificate this must be manually extracted. There
364*2175Sjp161948should be some heuristic that determines the correct encryption certificate.
365*2175Sjp161948
366*2175Sjp161948Ideally a database should be maintained of a certificates for each email address.
367*2175Sjp161948
368*2175Sjp161948The code doesn't currently take note of the permitted symmetric encryption
369*2175Sjp161948algorithms as supplied in the SMIMECapabilities signed attribute. this means the
370*2175Sjp161948user has to manually include the correct encryption algorithm. It should store
371*2175Sjp161948the list of permitted ciphers in a database and only use those.
372*2175Sjp161948
373*2175Sjp161948No revocation checking is done on the signer's certificate.
374*2175Sjp161948
375*2175Sjp161948The current code can only handle S/MIME v2 messages, the more complex S/MIME v3
376*2175Sjp161948structures may cause parsing errors.
377*2175Sjp161948
378*2175Sjp161948=cut
379