Pileus Git - ~andy/fetchmail/blob - README.SSL-SERVER

   1 SSL server requirements
   2 -----------------------
   3
   4 In order to let any mail client (not just fetchmail) verify server certificates
   5 properly, so that users can be sure their connection is not eavesdropped, there
   6 are several requirements that need to be fulfilled.
   7
   8 1. Match certificate and DNS names:
   9
  10    The server certificate's "common name" or "subject alternative name" must
  11    match the name by which clients are connecting. Avoid the use of wildmats if
  12    possible, not all clients support them (fetchmail does).
  13
  14    This may sound trivial, but for load balancing and failover setups, it may
  15    not be obvious.
  16
  17 2. Provide the *full* certificate chain
  18
  19    Many SSL documents tell you to install the server certificate, silently
  20    assuming that it were directly signed by a trusted root certification
  21    authority (CA).
  22
  23    If your server certificate is not directly signed by the root certification
  24    authority (root CA), then you are using intermediate CA. In this case, you
  25    *MUST* (as per the TLS standard) provide *ALL* intermediate certificates.
  26
  27    If you fail to provide intermediate certificates, clients can only connect
  28    if the end user overrides/disables security warnings in his/her software,
  29    and this disables the detection of eavesdroppers.
  30
  31    The intermediate CA certificates must be issued after the server's
  32    certificate in proper order, that is:
  33    first the intermediate CA cert that signed the servers' certificate, then
  34    the intermedate CA cert that signed the previous intermediate CA, and all
  35    the way back to the root CA cert (which you should omit).
  36
  37    You can optionally add the root CA certificate, but this is redundant, as
  38    the client needs to have that installed anyways (see 3 below) in its store
  39    of trusted root certification authorities in order to verify certificates
  40    that this root CA has signed.
  41
  42    For software that does not offer "chain certificate" options, but that
  43    supports reading certificates in PEM format, it is usually sufficient to
  44    concatenate all the certs in proper order (again, from server to root).
  45
  46 3. Provide the *root* CA's certificate separately.
  47
  48    Provide the root CA's certificate in a place where your end users will
  49    quickly and easily find it, or provide a link to it. Depending on which mail
  50    software your clients use, it may not be pre-installed, and users require
  51    this root CA to verify your SSL server certificate, and possibly
  52    intermediate certificates.
  53
  54    This is particularly important if you're using local self-signed
  55    certificates, as these are never preinstalled into end-users clients.
  56
  57    Your technical support team should have the finger prints of this root CA
  58    readily available at least in MD5 and SHA1 formats and offer to clients and
  59    be ready to answer client questions as to the fingerprints (for
  60    verification) and installation in commonly used clients.