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