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:
DNS:we.webeloping.es, DNS:webeloping.es, DNS:
imap.webeloping.es, DNS:smtp.webeloping.es, DNS:mail.webeloping.es, DNS:
demo.webeloping.es, DNS:test.webeloping.es, DNS:*.webeloping.es, DNS:
webeloping.com, DNS:imap.webeloping.com, DNS:smtp.webeloping.com, DNS:
mail.webeloping.com, DNS:we.webeloping.com, DNS:demo.webeloping.com, DNS:
test.webeloping.com, DNS:*.webeloping.com
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-us...@dukhovni.org
> 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.
