Cert Hostname DOES NOT VERIFY

My domain is:mon-voyage-a-cuba.com

In order to have one POSTFIX/DOVECOT certificate for several domains I ran this command:
letsencrypt-auto certonly --rsa-key-size 4096 --email xxx@webologix.
com --webroot -w /var/www/webologix.com/web -d webologix.com -d www.webologix.com -w /var/www/php
-web-service.net/web -d php-web-service.net -d www.php-web-service.net -w /var/www/mon-voyage-a-c
uba.com/web -d mon-voyage-a-cuba.com -d www.mon-voyage-a-cuba.com

It produced this output:
Using https://www.checktls.com/TestReceiver I get this error:
Cert Hostname DOES NOT VERIFY (mail.mon-voyage-a-cuba.com != webologix.com | DNS:mon-voyage-a-cuba.com | DNS:php-web-service.net | DNS:webologix.com | DNS:www.mon-voyage-a-cuba.com | DNS:www.php-web-service.net | DNS:www.webologix.com)
So email is encrypted but the host is not verified

My web server is (include version):
Apache 2.4

The operating system my web server runs on is (include version):
Debian 8

My hosting provider, if applicable, is:
ovh

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

Your MX record is for mail. but you didn’t include that name on your certificate:

mon-voyage-a-cuba.com.  600     IN      MX      10 mail.mon-voyage-a-cuba.com.

Hi @kmc,

Repeat the test but this time, expand Full Version and check this option Relax "*" match. Without this check, the validation only takes care of the Common Name appeared on the cert but this is deprecated and all clients should check the DNS Alternative names.

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Also, as @_az said you should include mail.mon-voyage-a-cuba.com in your cert.

Cheers,
sahsanu

when I included mail.mon-voyage-a-cuba.com in my cert it failed saying it couldn’t access the mail.mon-voyage-a-cuba.com/.well-known directory.
Should I use the -standalone or -apache versions ?

Without mail.mon-voyage-a-cuba.com mentioned, the test on initial certificate generated succeeds with Relax “*” option and Thunderbird seems to connect to the server but I still can’t connect through php mailer script running on smtp server localhost.
Could it be certificate matter or should I search for another reason ?

Try to use DNS-01 authentication for non web usage if you can. Otherwise you have to have a web server answering for mail.mon-voyage-a-cuba.com which is possible but unusual.

In general: You must setup a web server answering to HTTP requests for your cert domains for apache or nginx authenticators. If you don’t have a service running port 80 on the requesting machine you can use the standalone authenticator.

looks complicated for renewal.

I solved by building a certificate for mail server purpose in standalone mode, seperated from other regular https certificates, like this:

root@ns1:/opt/letsencrypt# ./letsencrypt-auto certonly --standalone --preferred-challenges http -d mail.webologix.com -d smtp.webologix.com  -d mail.mon-voyage-a-cuba.com -d smtp.mon-voyage-a-cuba.com  -d mail.php-web-service.net -d smtp.php-web-service.net 

Thanks for your help

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.