Loading ...
Sorry, an error occurred while loading the content.

StartSSL.com SSL Class2 Certificate and Postfix

Expand Messages
  • Pau Peris
    Hi all, currently my `Postfix 2.11` instance runs TLS on a `GoDaddy SSL Certificate` but as i would like to be able to access my server from smtp.domain.com as
    Message 1 of 11 , Mar 22, 2014
    • 0 Attachment
      Hi all,

      currently my `Postfix 2.11` instance runs TLS on a `GoDaddy SSL Certificate` but as i would like to be able to access my server from smtp.domain.com as well as imap.domain.com, domain.com or domain.es i bought a cheap SSL Class2 Certificate at startssl.com website. But after updating Postfix configuration replacing the old Godaddy SSL Certificate by the new StartSSL.com SSL Class2 Certificate, email desktop clients complain about the smtp.domain.com not being the Common Name domain.com.

      I've configured `nginx and everything seems to work fine when accessing to any of the following domain names and domain alternative names: 



      On Postfix i have the following configuration for Godaddy Certificate:

      smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
      smtpd_tls_key_file=/etc/ssl/private/domain.key
      smtp_tls_CAfile=/etc/ssl/certs/sf_bundle.crt
      smtp_tls_CApath=/etc/ssl/certs


      For StartSSL.com Class2 Certificate i tried the following setup combinations without luck:

      Combination1

      smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
      smtpd_tls_key_file=/etc/ssl/private/domain.key
      smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
      smtp_tls_CApath=/etc/ssl/certs


      Combination2
      cat domain.crt sub.class2.server.ca.pem >> mycert.crt

      smtpd_tls_cert_file=/etc/ssl/certs/mycert.crt
      smtpd_tls_key_file=/etc/ssl/private/domain.key
      smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
      smtp_tls_CApath=/etc/ssl/certs

      Combination3
      cat domain.crt sub.class2.server.ca.pem >> /etc/ssl/certs/ca-certificates.crt

      smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
      smtpd_tls_key_file=/etc/ssl/private/domain.key
      smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
      smtp_tls_CApath=/etc/ssl/certs

      As i see, the main issue come because clients can't see the alternative names which are located under x509v3 but HTTP browsers like chrome or Firefox do.

    • Viktor Dukhovni
      ... The vendor is largely irrelevant. Can you be specific about the content of the certificate? - What is its subject commonName? - What are the DNS
      Message 2 of 11 , Mar 22, 2014
      • 0 Attachment
        On Sat, Mar 22, 2014 at 12:17:28PM +0100, Pau Peris wrote:

        > Currently my `Postfix 2.11` instance runs TLS on a `GoDaddy SSL
        > Certificate`

        The vendor is largely irrelevant. Can you be specific about the
        content of the certificate?

        - What is its subject commonName?
        - What are the DNS subjectAltNames if any?

        > but as I would like to be able to access my server from
        > smtp.domain.com as well as imap.domain.com, domain.com or domain.es

        What *exactly* do you mean by "access my server from <some-domain>"?

        > I bought a cheap SSL Class2 Certificate at startssl.com website.

        The vendor is largely irrelevant. Can you be specific about the
        content of the certificate?

        - What is its subject commonName?
        - What are the DNS subjectAltNames if any?

        > But after
        > updating Postfix configuration replacing the old Godaddy SSL Certificate by
        > the new StartSSL.com SSL Class2 Certificate,

        This is an anecdote, what parameters where changed and exactly how?


        > Email desktop clients complain
        > about the smtp.domain.com not being the Common Name domain.com.

        Presumably the new certificate does not have the right name or
        subjectAltName or these MUAs don't support subjectAltNames.

        > I've configured `nginx and everything seems to work fine when accessing to
        > any of the following domain names and domain alternative names:
        >
        > [ list of domains ]

        Another anecdote, without any specific details, and with the client
        software presumably HTTP browsers this time, so this is not terribly
        useful.

        > On Postfix I have the following configuration for Godaddy Certificate:
        >
        > smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
        > smtpd_tls_key_file=/etc/ssl/private/domain.key
        > smtp_tls_CAfile=/etc/ssl/certs/sf_bundle.crt
        > smtp_tls_CApath=/etc/ssl/certs

        MUAs should be able to authenticate your server provided they are
        configured to reach it via a domain name that matches some name in
        "domain.crt". You need to post the names in that original certificate.

        The file "domain.crt" should contain the leaf certificate (first)
        as well its "intermediate" issuer certificates, each issuer below
        the corresponding "subject". The root issuer is optional (with
        PKIX, and not with DANE, but no MUAs implement DANE yet).

        > For StartSSL.com Class2 Certificate I tried the following setup
        > combinations without luck:
        >
        > Combination1
        >
        > smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
        > smtpd_tls_key_file=/etc/ssl/private/domain.key
        > smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
        > smtp_tls_CApath=/etc/ssl/certs

        MUAs should be able to authenticate your server provided they are
        configured to reach it via a domain name that matches some name in
        "domain.crt". You need to post the names in this new certificate.

        > Combination2
        > cat domain.crt sub.class2.server.ca.pem >> mycert.crt

        Does that second file contain the issuer of "domain.crt"? If so
        this is required.

        http://www.postfix.org/TLS_README.html#server_cert_key

        if there is more than one intermediate CA (multiple CAs between
        the root and your leaf server) you need to include them all.

        > smtpd_tls_cert_file=/etc/ssl/certs/mycert.crt
        > smtpd_tls_key_file=/etc/ssl/private/domain.key

        This might work better, but not if the new certificate *name* is the
        problem. Is it untrusted, or trusted, but has the wrong name?

        > Combination3
        > cat domain.crt sub.class2.server.ca.pem >> /etc/ssl/certs/ca-certificates.crt
        >
        > smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
        > smtpd_tls_key_file=/etc/ssl/private/domain.key
        > smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
        > smtp_tls_CApath=/etc/ssl/certs

        This is silly. The CA file is for the Postfix SMTP client verifying remote
        SMTP servers, not for the Postfix SMTP server to include in its own chain.

        > As I see, the main issue come because clients can't see the alternative
        > names which are located under x509v3 but HTTP browsers like chrome or
        > Firefox do.

        If that's the issue, messing around with intermediate CAs won't help you.
        the subject CN of the certificate needs to be what these outdated clients
        expect.

        -
        Viktor.
      • Pau Peris
        Hi Viktor, thanks a lot for your time. Here s the information you requested me to post: Common Name (CN) we.webeloping.es X509v3 Subject Alternative Name:
        Message 3 of 11 , Mar 26, 2014
        • 0 Attachment
          Hi Viktor,

          thanks a lot for your time. Here's the information you requested me to post:

          Common Name (CN) we.webeloping.es

          X509v3 Subject Alternative Name: 

          By "access my server from <some-domain>" i mean:
            Configuring a Desktop email client to access IMAP and SMTP servers we.webeloping.es and we.webeloping.es respectively works liek a charm while using imap.webeloping.es and smtp.webeloping.es makes the email client show the typical SSL warning complaining about the host not being the common name

          Do you know what could be wrong?

          On Sat, Mar 22, 2014 at 7:22 PM, Viktor Dukhovni <postfix-users@...> wrote:
          On Sat, Mar 22, 2014 at 12:17:28PM +0100, Pau Peris wrote:

          > Currently my `Postfix 2.11` instance runs TLS on a `GoDaddy SSL
          > Certificate`

          The vendor is largely irrelevant.  Can you be specific about the
          content of the certificate?

              - What is its subject commonName?
              - What are the DNS subjectAltNames if any?

          > but as I would like to be able to access my server from
          > smtp.domain.com as well as imap.domain.com, domain.com or domain.es

          What *exactly* do you mean by "access my server from <some-domain>"?

          > I bought a cheap SSL Class2 Certificate at startssl.com website.

          The vendor is largely irrelevant.  Can you be specific about the
          content of the certificate?

              - What is its subject commonName?
              - What are the DNS subjectAltNames if any?

          > But after
          > updating Postfix configuration replacing the old Godaddy SSL Certificate by
          > the new StartSSL.com SSL Class2 Certificate,

          This is an anecdote, what parameters where changed and exactly how?


          > Email desktop clients complain
          > about the smtp.domain.com not being the Common Name domain.com.

          Presumably the new certificate does not have the right name or
          subjectAltName or these MUAs don't support subjectAltNames.

          > I've configured `nginx and everything seems to work fine when accessing to
          > any of the following domain names and domain alternative names:
          >
          > [ list of domains ]

          Another anecdote, without any specific details, and with the client
          software presumably HTTP browsers this time, so this is not terribly
          useful.

          > On Postfix I have the following configuration for Godaddy Certificate:
          >
          > smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
          > smtpd_tls_key_file=/etc/ssl/private/domain.key
          > smtp_tls_CAfile=/etc/ssl/certs/sf_bundle.crt
          > smtp_tls_CApath=/etc/ssl/certs

          MUAs should be able to authenticate your server provided they are
          configured to reach it via a domain name that matches some name in
          "domain.crt".  You need to post the names in that original certificate.

          The file "domain.crt" should contain the leaf certificate (first)
          as well its "intermediate" issuer certificates, each issuer below
          the corresponding "subject".  The root issuer is optional (with
          PKIX, and not with DANE, but no MUAs implement DANE yet).

          > For StartSSL.com Class2 Certificate I tried the following setup
          > combinations without luck:
          >
          > Combination1
          >
          > smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
          > smtpd_tls_key_file=/etc/ssl/private/domain.key
          > smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
          > smtp_tls_CApath=/etc/ssl/certs

          MUAs should be able to authenticate your server provided they are
          configured to reach it via a domain name that matches some name in
          "domain.crt".  You need to post the names in this new certificate.

          > Combination2
          > cat domain.crt sub.class2.server.ca.pem >> mycert.crt

          Does that second file contain the issuer of "domain.crt"?  If so
          this is required.

              http://www.postfix.org/TLS_README.html#server_cert_key

          if there is more than one intermediate CA (multiple CAs between
          the root and your leaf server) you need to include them all.

          > smtpd_tls_cert_file=/etc/ssl/certs/mycert.crt
          > smtpd_tls_key_file=/etc/ssl/private/domain.key

          This might work better, but not if the new certificate *name* is the
          problem.  Is it untrusted, or trusted, but has the wrong name?

          > Combination3
          > cat domain.crt sub.class2.server.ca.pem >> /etc/ssl/certs/ca-certificates.crt
          >
          > smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
          > smtpd_tls_key_file=/etc/ssl/private/domain.key
          > smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
          > smtp_tls_CApath=/etc/ssl/certs

          This is silly.  The CA file is for the Postfix SMTP client verifying remote
          SMTP servers, not for the Postfix SMTP server to include in its own chain.

          > As I see, the main issue come because clients can't see the alternative
          > names which are located under x509v3 but HTTP browsers like chrome or
          > Firefox do.

          If that's the issue, messing around with intermediate CAs won't help you.
          the subject CN of the certificate needs to be what these outdated clients
          expect.

          -
                  Viktor.



          --
          Pau Peris Rodriguez
          Chief Executive Officer (CEO)
          Tel: 669650292
          C/Balmes 211, Principal Segunda
          Barcelona 08006
          http://www.webeloping.es

          Aquest correu electrònic conté informació de caràcter confidencial dirigida exclusivament al seu/s destinatari/s en còpia present. Tant mateix, queda prohibida la seva divulgació, copia o distribució a tercers sense prèvia autorització escrita per part de Pau Peris Rodriguez. En cas d'haver rebut aquesta informació per error, es demana que es notifiqui immediatament d'aquesta circumstancia mitjançant la direcció electrònica del emissor.
        • Viktor Dukhovni
          ... s/from/as/ ... Well, now you know what not to do. :-( The mail client wants the server name in the CN. -- Viktor.
          Message 4 of 11 , Mar 26, 2014
          • 0 Attachment
            On Wed, Mar 26, 2014 at 09:13:58PM +0100, Pau Peris wrote:

            > Common Name (CN) we.webeloping.es
            >
            > X509v3 Subject Alternative Name:
            > DNS:webeloping.com,
            > DNS:demo.webeloping.com,
            > DNS:imap.webeloping.com,
            > DNS:mail.webeloping.com,
            > DNS:smtp.webeloping.com,
            > DNS:test.webeloping.com,
            > DNS:we.webeloping.com,
            > DNS:*.webeloping.com
            > DNS:webeloping.es,
            > DNS:*.webeloping.es,
            > DNS:demo.webeloping.es,
            > DNS:imap.webeloping.es,
            > DNS:mail.webeloping.es,
            > DNS:smtp.webeloping.es,
            > DNS:test.webeloping.es,
            > DNS:we.webeloping.es,


            > By "access my server from <some-domain>" I mean:
            > Configuring a desktop email client to access IMAP and SMTP servers.

            s/from/as/

            > we.webeloping.es and we.webeloping.es respectively work like a charm, while
            > using imap.webeloping.es and smtp.webeloping.es makes the email client show
            > the typical SSL warning complaining about the host not being the common name

            Well, now you know what not to do. :-( The mail client wants the server
            name in the CN.

            --
            Viktor.
          • Pau Peris
            Are you really sure? I mean, do you know where can i find information about this topic? As i planned to operate that way, buying cheap ssl certs for multiple
            Message 5 of 11 , Mar 26, 2014
            • 0 Attachment

              Are you really sure? I mean, do you know where can i find information about this topic? As i planned to operate that way, buying cheap ssl certs for multiple domains/subdomains i would like to be sure before discarding that procedure.

              Thanks a lot!!

              Sent from my Android mobile, excuse the brevity.

              On Mar 26, 2014 9:28 PM, "Viktor Dukhovni" <postfix-users@...> wrote:
              On Wed, Mar 26, 2014 at 09:13:58PM +0100, Pau Peris wrote:

              > Common Name (CN) we.webeloping.es
              >
              > X509v3 Subject Alternative Name:
              >       DNS:webeloping.com,
              >       DNS:demo.webeloping.com,
              >       DNS:imap.webeloping.com,
              >       DNS:mail.webeloping.com,
              >       DNS:smtp.webeloping.com,
              >       DNS:test.webeloping.com,
              >       DNS:we.webeloping.com,
              >       DNS:*.webeloping.com
              >       DNS:webeloping.es,
              >       DNS:*.webeloping.es,
              >       DNS:demo.webeloping.es,
              >       DNS:imap.webeloping.es,
              >       DNS:mail.webeloping.es,
              >       DNS:smtp.webeloping.es,
              >       DNS:test.webeloping.es,
              >       DNS:we.webeloping.es,


              > By "access my server from <some-domain>" I mean:
              > Configuring a desktop email client to access IMAP and SMTP servers.

                      s/from/as/

              > we.webeloping.es and we.webeloping.es respectively work like a charm, while
              > using imap.webeloping.es and smtp.webeloping.es makes the email client show
              > the typical SSL warning complaining about the host not being the common name

              Well, now you know what not to do. :-(  The mail client wants the server
              name in the CN.

              --
                      Viktor.
            • lists@rhsoft.net
              the problem is that you can t control what the client expects there are a lot of clients, recent and outdated rule of thumbs: avoid all that domain-specific
              Message 6 of 11 , Mar 26, 2014
              • 0 Attachment
                the problem is that you can't control what the client expects
                there are a lot of clients, recent and outdated

                rule of thumbs:
                avoid all that domain-specific crap in caes of mail and just
                use and communicate "mail.yourdomain.tld" indepdendent what
                domains you are hosting - that scales and works in any case

                we are hosting some hundret mail-domains and have *one* servername

                Am 26.03.2014 22:51, schrieb Pau Peris:
                > Are you really sure? I mean, do you know where can i find information about this topic? As i planned to operate
                > that way, buying cheap ssl certs for multiple domains/subdomains i would like to be sure before discarding that
                > procedure.
                >
                > On Mar 26, 2014 9:28 PM, "Viktor Dukhovni" <postfix-users@... <mailto:postfix-users@...>> wrote:
                >
                > On Wed, Mar 26, 2014 at 09:13:58PM +0100, Pau Peris wrote:
                >
                > > Common Name (CN) we.webeloping.es <http://we.webeloping.es>
                > >
                > > X509v3 Subject Alternative Name:
                > > DNS:webeloping.com <http://webeloping.com>,
                > > DNS:demo.webeloping.com <http://demo.webeloping.com>,
                > > DNS:imap.webeloping.com <http://imap.webeloping.com>,
                > > DNS:mail.webeloping.com <http://mail.webeloping.com>,
                > > DNS:smtp.webeloping.com <http://smtp.webeloping.com>,
                > > DNS:test.webeloping.com <http://test.webeloping.com>,
                > > DNS:we.webeloping.com <http://we.webeloping.com>,
                > > DNS:*.webeloping.com <http://webeloping.com>
                > > DNS:webeloping.es <http://webeloping.es>,
                > > DNS:*.webeloping.es <http://webeloping.es>,
                > > DNS:demo.webeloping.es <http://demo.webeloping.es>,
                > > DNS:imap.webeloping.es <http://imap.webeloping.es>,
                > > DNS:mail.webeloping.es <http://mail.webeloping.es>,
                > > DNS:smtp.webeloping.es <http://smtp.webeloping.es>,
                > > DNS:test.webeloping.es <http://test.webeloping.es>,
                > > DNS:we.webeloping.es <http://we.webeloping.es>,
                >
                >
                > > By "access my server from <some-domain>" I mean:
                > > Configuring a desktop email client to access IMAP and SMTP servers.
                >
                > s/from/as/
                >
                > > we.webeloping.es <http://we.webeloping.es> and we.webeloping.es <http://we.webeloping.es> respectively work
                > like a charm, while
                > > using imap.webeloping.es <http://imap.webeloping.es> and smtp.webeloping.es <http://smtp.webeloping.es> makes
                > the email client show
                > > the typical SSL warning complaining about the host not being the common name
                >
                > Well, now you know what not to do. :-( The mail client wants the server
                > name in the CN.
              • Viktor Dukhovni
                ... Do you disbelive you own findings? You report that the same certificate is accepted when the MUA is configured to connect to the subject commonName and
                Message 7 of 11 , Mar 26, 2014
                • 0 Attachment
                  On Wed, Mar 26, 2014 at 10:51:29PM +0100, Pau Peris wrote:

                  > Are you really sure? I mean, do you know where can i find information about
                  > this topic?

                  Do you disbelive you own findings? You report that the same
                  certificate is accepted when the MUA is configured to connect to
                  the subject commonName and rejected when the client is configured
                  to connect to a DNS subjectAltName. What conclusion do you draw
                  about the MUA?

                  > As i planned to operate that way, buying cheap ssl certs for
                  > multiple domains/subdomains i would like to be sure before discarding that
                  > procedure.

                  The subject DN needs to be compatible with the needs of clients
                  that don't support subjectAltNames. This may limit your freedom
                  to choose server names and will constrain the set of usable
                  certificates. Clients that support subjectAltNames can be handled
                  by adding appropriate DNS subjectAltNames.

                  --
                  Viktor.
                • Pau Peris
                  Hi Viktor, Thank you very much. Yo re awesome help!! Last, yes, i mis belief my findings jejeje I just feel out of business here. Thanks again. Sent from my
                  Message 8 of 11 , Mar 26, 2014
                  • 0 Attachment

                    Hi Viktor,

                    Thank you very much. Yo're awesome help!!

                    Last, yes, i mis belief my findings jejeje I just feel out of business here.

                    Thanks again.

                    Sent from my Android mobile, excuse the brevity.

                    On Mar 26, 2014 11:00 PM, "Viktor Dukhovni" <postfix-users@...> wrote:
                    On Wed, Mar 26, 2014 at 10:51:29PM +0100, Pau Peris wrote:

                    > Are you really sure? I mean, do you know where can i find information about
                    > this topic?

                    Do you disbelive you own findings?  You report that the same
                    certificate is accepted when the MUA is configured to connect to
                    the subject commonName and rejected when the client is configured
                    to connect to a DNS subjectAltName.  What conclusion do you draw
                    about the MUA?

                    > As i planned to operate that way, buying cheap ssl certs for
                    > multiple domains/subdomains i would like to be sure before discarding that
                    > procedure.

                    The subject DN needs to be compatible with the needs of clients
                    that don't support subjectAltNames.  This may limit your freedom
                    to choose server names and will constrain the set of usable
                    certificates.  Clients that support subjectAltNames can be handled
                    by adding appropriate DNS subjectAltNames.

                    --
                            Viktor.
                  • Pau Peris
                    Just one last question. Do you think I could set postfix to use multiple ceertificates and their respective private keys so when a client connects to
                    Message 9 of 11 , Mar 26, 2014
                    • 0 Attachment

                      Just one last question. Do you think I could set postfix to use multiple ceertificates and their respective private keys so when a client connects to example.com Postfix makes use of example.crt certificate but when connecting to example2.com Postfix makes use of example2.crt?

                      Thanks again

                      Sent from my Android mobile, excuse the brevity.

                      On Mar 26, 2014 11:04 PM, "Pau Peris" <pau@...> wrote:

                      Hi Viktor,

                      Thank you very much. Yo're awesome help!!

                      Last, yes, i mis belief my findings jejeje I just feel out of business here.

                      Thanks again.

                      Sent from my Android mobile, excuse the brevity.

                      On Mar 26, 2014 11:00 PM, "Viktor Dukhovni" <postfix-users@...> wrote:
                      On Wed, Mar 26, 2014 at 10:51:29PM +0100, Pau Peris wrote:

                      > Are you really sure? I mean, do you know where can i find information about
                      > this topic?

                      Do you disbelive you own findings?  You report that the same
                      certificate is accepted when the MUA is configured to connect to
                      the subject commonName and rejected when the client is configured
                      to connect to a DNS subjectAltName.  What conclusion do you draw
                      about the MUA?

                      > As i planned to operate that way, buying cheap ssl certs for
                      > multiple domains/subdomains i would like to be sure before discarding that
                      > procedure.

                      The subject DN needs to be compatible with the needs of clients
                      that don't support subjectAltNames.  This may limit your freedom
                      to choose server names and will constrain the set of usable
                      certificates.  Clients that support subjectAltNames can be handled
                      by adding appropriate DNS subjectAltNames.

                      --
                              Viktor.
                    • Viktor Dukhovni
                      ... There is no server-side SNI support in Postfix. MX records obviate the need to jump through this hoop for MTA to MTA traffic. While this is perhaps a bit
                      Message 10 of 11 , Mar 26, 2014
                      • 0 Attachment
                        On Wed, Mar 26, 2014 at 11:21:32PM +0100, Pau Peris wrote:

                        > Just one last question. Do you think I could set postfix to use multiple
                        > certificates and their respective private keys so when a client connects
                        > to example.com Postfix makes use of example.crt certificate but when
                        > connecting to example2.com Postfix makes use of example2.crt?

                        There is no server-side SNI support in Postfix. MX records obviate
                        the need to jump through this hoop for MTA to MTA traffic. While
                        this is perhaps a bit more useful for submission, the code to
                        support server-side SNI has not been developed.

                        If you want multiple TLS personalities, you need multiple TCP
                        endpoints, with differently configured smtpd(8) processes for each
                        domain.

                        It would be nice if MUAs implement SRV records for imap and
                        submission, there's a draft RFC for it, but most MUAs are rather
                        old and nobody is actively adding new features to them.

                        --
                        Viktor.
                      • Pau Peris
                        Finally i got startssl.com class 2 SSL Certificate working with Postfix 2.11, so my current configuration works fine for multiple domains and subdomains.
                        Message 11 of 11 , Mar 27, 2014
                        • 0 Attachment
                          Finally i got startssl.com class 2 SSL Certificate working with Postfix 2.11, so my current configuration works fine for multiple domains and subdomains.

                          Here's the working configuration just in case anyone needs it.

                          Postfix /etc/postfix/main.cf
                          smtpd_tls_cert_file=/etc/ssl/certs/class2.webeloping_es.pem
                          smtpd_tls_key_file=/etc/ssl/private/class2.webeloping_es.key
                          ## This file was download from startssl.com
                          smtp_tls_CAfile=/etc/ssl/certs/startssl_ca-bundle.pem
                          smtp_tls_CApath=/etc/ssl/certs


                          $ cat /root/SSL/startssl.com/class2.webeloping_es.crt /root/SSL/startssl.com/class2.webeloping_es.key >> /etc/ssl/private/startssl-crt_key.pem 

                          Courier Imap /etc/courier/imapd-ssl
                          TLS_CERTFILE=/etc/ssl/private/startssl-crt_key.pem
                          TLS_TRUSTCERTS=/etc/ssl/certs/startssl_ca-bundle.pem.pem


                          Thanks Viktor for all your help!

                          On Wed, Mar 26, 2014 at 11:38 PM, Viktor Dukhovni <postfix-users@...> wrote:
                          On Wed, Mar 26, 2014 at 11:21:32PM +0100, Pau Peris wrote:

                          > Just one last question. Do you think I could set postfix to use multiple
                          > certificates and their respective private keys so when a client connects
                          > to example.com Postfix makes use of example.crt certificate but when
                          > connecting to example2.com Postfix makes use of example2.crt?

                          There is no server-side SNI support in Postfix.  MX records obviate
                          the need to jump through this hoop for MTA to MTA traffic.  While
                          this is perhaps a bit more useful for submission, the code to
                          support server-side SNI has not been developed.

                          If you want multiple TLS personalities, you need multiple TCP
                          endpoints, with differently configured smtpd(8) processes for each
                          domain.

                          It would be nice if MUAs implement SRV records for imap and
                          submission, there's a draft RFC for it, but most MUAs are rather
                          old and nobody is actively adding new features to them.

                          --
                                  Viktor.
                        Your message has been successfully submitted and would be delivered to recipients shortly.