When I try to use POP3 with SSL, Gmail complains: "Certificate is self-signed"

[Richard G]

About cloudflare, "server.hostname.com", must have record in the cloudflare.

Oke so that would mean he would need to add a "server" A record in his primary domain setting.

Mail records are all visible there if I'm not mistaken, or does that work in another way at cloudflare? I don't know what that "proxied" means or does behind the domain name record and the www record.

 

[Ohm J]

yes, All records that need access from outside, must add in cloudflare and must be "grey cloud". Behide proxy mail won't work. because even you push your domain behide proxy, they can saw your server IPs from email raw data that you sending to other.

 

[Richard G]

and must be "grey cloud".

Oke so DNS Only (like in his screenshot) is not good either then?

 

[Ohm J]

Some important records must be grey cloud, Like "server", "mail", ..etc..

So it useless if only 2 records "www" or "domain.com" behide proxy. Because other records need to be "grey cloud"( bypass proxy ).

It can be only serve as cache, but can't hide or protect yourself from ddos. Because they can saw your real IPs from other records.
if you don't care about this, it should be fine.

 

[Richard G]

Because other records need to be "grey cloud"( bypass proxy ).

Yes but I ment from the screenshot I seen only proxy and DNS Only. So I was wondering if the "dns only" was the grey cloud option you ment, or if there is a specific seperate "grey cloud" option in the pulldown.

 

[cmyden]

Thanks jamgames2 and Zhenyapan! And of course a big thanks again to Richard.

I've taken all of the info from this thread and Richard's guide and compiled into the course of action I'll be taking.

If I've screwed anything up, missed anything, or doing anything in the wrong order, please let me know!



Step 1: Set the hostname via SSH

Via SSH as root:

# hostnamectl set-hostname server.primarydomain.com

- Now check your /etc/hostname file and make sure server.primarydomain.com is there.

If not, adjust it.


- Check your /etc/hosts file and make sure it contains this info:

127.0.0.1 localhost.localdomain localhost
your.ip.ad.res server.primarydomain.com server


Step 2: Reboot your server and then issue these commands to make sure they return the correct hostname.

# hostname

# hostname -f

Both commands should return: server.primarydomain.com



Step 3: Now go into the DA control panel and change the hostname to server.primarydomain.com

Admin -> Server Manager -> Administrator Settings -> Server Settings

Server's Hostname:

change from www.primarydomain.com to server.primarydomain.com



Step 4: Create DNS records on the server for server.primarydomain.com
and the directory for it under /etc/virtual

Admin -> Server Manager -> DNS Administration -> Add DNS Zone

- First check to see if server-xx-xx-xx-xx.da.direct exists.

If it does, delete it.


- Now add the DNS Zone:

domain: server.primarydomain.com <-- no period

ip address: ip.add.re.ss

ns1.primarydomain.com <-- no period

ns2.primarydomain.com <-- no period


- Now go into the DNS Zone: server.primarydomain.com

You should see these records (in addition to the records that are already there. Leave those additional records there)


Name TTL Type Value

server.primarydomain.com. 14400 A ip.add.re.ss

server.primarydomain.com. NS ns1.primarydomain.com. <-- period at end

server.primarydomain.com. NS ns2.primarydomain.com. <-- period at end


- Due to a bug, you need to login via SSH and go to the /etc/virtual directory and
make sure that the directory server.primarydomain.com exists.

^^ I did not encounter this bug, the directory was there.

If not, create it and chown it to mail:mail
And set the permissions to 711

# cd /etc/virtual
# mkdir server.primarydomain.com
# chown mail:mail server.primarydomain.com


Step 5: Create a DKIM record for the hostname and copy the records to Cloudflare

cd /usr/local/directadmin/scripts
./dkim_create.sh server.primarydomain.com

- If all is correct it will create the same DKIM record as in your primarydomain.com

But you should check to make sure it's correct (in my case it was not, no idea why)


- In the end, between DirectAdmin and CloudFlare you're trying to achieve this:



The only kind of tricky part is copying the 'server.primarydomain.com' key to Cloudflare.

It goes under CloudFlare -> PrimaryDomain.com -> but the 'Name' of the Cloudflare record should be: x._domainkey.server


Step 6: CloudFlare

- Add an A record for server.primarydomain.com

Disable the Proxy (set to 'DNS only')




^^ Wondering if maybe the CloudFlare step should be done earlier, like right after Step 1. Can't hurt anything?


- If you use CloudFlare as external DNS, I would suggest for the primary domain to also copy the SPF and DKIM TXT records.



Step 7: Ask owner of the Server IP Address (Webhost) to add a PTR / Reverse DNS record for IPv4 and IPv6


Hello,

Please add a PTR / Reverse DNS record for my IPv4 address: A.B.C.D

And point it to: server.primarydomain.com.


And please add one for my IPv6 address as well: y:y:y:y:y:y:x.x.x.x.


Step 8: Once the PTR / Reverse DNS records have been added

Wait about a half hour for the hostname to resolve.

# nslookup [server ip address]

It should resolve to server.primarydomain.com


- Now you can request a new SSL certificate for your hostname.

cd /usr/local/directadmin/scripts
./letsencrypt.sh request_single server.primarydomain.com 4096


- Once you have a certificate for your hostname, you can turn on ssl=1 in directadmin.conf



Step 9: Now let's see what happens when I run:

# openssl s_client -showcerts -connect ip.ad.dre.ss:995

Woo hoo! Success. No more 'self signed' certificate.


And Gmail now approves of my POP3 mail server over Port 995.

Be sure to use: server.primarydomain.com
And not your IP address.


If I've screwed anything up, missed anything, or in the wrong order, please let me know!

Thank you

 

[Richard G]

Check your /etc/hosts file and make sure it contains this info:

127.0.0.1 localhost
your.ip.ad.res server.primarydomain.com

should be
127.0.0.1 localhost.localdomain localhost your.ip.ad.res server.primarydomain.com server

# chown mail:mail server.primarydomain.com

(should I CHMOD 600?)

Ah I see I mist that one, all others are normally 711 so do CHMOD 711 to keep everything the same. I will adjust my manual for this. Good find.

I would swap step 3 and 4, but wait the half an hour after creating the hostname via DNS administration.
So that waiting part belongs to the creation of the hostname DNS record.
After the wait and verify, the hostname certificate creation.

Step 6.

Hello,

Please add a PTR / Reverse DNS record for my IPv4 address: A.B.C.D

And point it to: server.primarydomain.com

And same for you ipv6.

End of story/manual.

Forget all you put below it. Don't use PTR records yourself in DA. It's extra work and does nothing.
Your host should now how to put in the rDNS/PTR records otherwise he's not competent enough.

Looks good!

 

[cmyden]

should be
127.0.0.1 localhost.localdomain localhost your.ip.ad.res server.primarydomain.com server


Ah I see I mist that one, all others are normally 711 so do CHMOD 711 to keep everything the same. I will adjust my manual for this. Good find.

I would swap step 3 and 4, but wait the half an hour after creating the hostname via DNS administration.
So that waiting part belongs to the creation of the hostname DNS record.
After the wait and verify, the hostname certificate creation.

Step 6.

And same for you ipv6.

End of story/manual.

Forget all you put below it. Don't use PTR records yourself in DA. It's extra work and does nothing.
Your host should now how to put in the rDNS/PTR records otherwise he's not competent enough.

Looks good!

Thank you, I have modified the steps above.

 

[Richard G]

Thank you, I have modified the steps above.

You're welcome.
Just to be sure, if you are installing a new server, then steps 3 and 4 are good, you don't need to swap them.

 

[cmyden]

So everything seemed to go well...

# hostnamectl set-hostname server.primarydomain.com

- /etc/hostname contained server,primarydomain.com

- /etc/hosts did *not* automatically contain:

your.ip.ad.res server.primarydomain.com server

Instead, it contained:

your.ip.ad.res www.primarydomain.com www

(my current hostname)


So I changed that line to:

your.ip.ad.res server.primarydomain.com server


- hostname and hostname -f both returned the correct response after reboot


- Admin -> Server Manager -> Administrator Settings -> Server Settings

Changed hostname to: server.primarydomain.com


- Admin -> Server Manager -> DNS Administration
-> PrimaryDomain.com (as the admin in admin level)

^^ I assume it was fine to add the new records here, and not as a new DNS Zone

- server-xx-xx-xx-xx.da.direct record did not exist

- added the new DNS records ....


- the bug did not seem to exist for me.

Under /etc/virtual my server.primarydomain.com directory was already created and with the correct permissions and owner

- Cloudflare A record is set. Pinging server.primarydomain.com returns my server IP.


- I waited an hour, and then tried: nslookup [server ip]

But I get: server can't find [reversed ip address].in-addr.arpa.: NXDOMAIN


I have not yet contacted the IP address owner (webhost) to create the PTR / rDNS record.

*Before* I have the PTR / rDNS record created, should the nslookup command work at this point?

Or not until after that step? I would think not until after.


Thank you

 

[Richard G]

- added the new DNS records ....

I normally write NS records for server in full but I guess it will be fine like that too.

Good to read the bug did not exist for you, it might have been fixed, although it still exist on automatic host creation on a new setup.

- I waited an hour, and then tried: nslookup [server ip]

You have to contact your host then, because the rDNS/PTR is not setup or not setup correctly yet.
Since you didn't do that yet, this result is logic.

This will only work ater this setup.
And only if this resolves then you should try and create the ssl certificate for your hostname.

 

[cmyden]

I normally write NS records for server in full but I guess it will be fine like that too.

Thank you, I was just wondering what you mean by this.

When I click on 'Add Record' to add an NS record, the input box looks like this.




Beside Name I enter: server

Do you mean you would enter something different?

Thanks

 

[Richard G]

When I click on 'Add Record' to add an NS record, the input box looks like this.

Ah oke, I mostly still work with the enhanced theme so I can punt server.domain.com. in there, that seems not to be required anymore in Evo theme.

So forget my comment about that. It's fine as you did.

 

[cmyden]

Woo hoo, success! After my host updated my PTR record, I continued with the steps:



Once your PTR / Reverse DNS records have been added....

- Wait half an hour

# nslookup ip.ad.dre.ss

It should resolve to server.primarydomain.com


- Now you can request a new SSL certificate for your hostname.

# cd /usr/local/directadmin/scripts
# ./letsencrypt.sh request_single server.primarydomain.com 4096


- Once you have a certificate for your hostname, you can turn on ssl=1 in directadmin.conf

# nano /usr/local/directadmin/conf/directadmin.conf
# systemctl restart directadmin

^^ Note: This was already done for me. I'm assuming during the Let's Encrypt certificate request.



Now let's see what happens when I run:

# openssl s_client -showcerts -connect ip.add.re.ss:995

Success! No more 'self signed' certificate.

And Gmail now approves of my POP3 mail server over Port 995 with SSL enabled.

Be sure to use: server.primarydomain.com
And not your IP address.


Thanks again Richard!


1. I assume it's normal that when accessing...

https://ip.ad.dr.es:2222

The browser complains the certificate is not valid for the IP address.

Accessing via...

https://server.primarydomain.com:2222

Works fine.


2. In Gmail, I am setting up individual accounts for each of my domains.

For POP, they will all obviously use for mail retrieval: server.primarydomain.com

But Gmail also gives you the capability to 'send as' your domain.

For example, I want to be able to send as:

[email protected]
[email protected]
[email protected]

In Gmail, when it asks for my SMTP server info for domain1.com

I used:

smtp.domain1.com port: 587 over TLS

And this does work. No complaints from Gmail.


But I'm wondering two things:

a) When I run:

# openssl s_client -showcerts -connect smtp.domain1.com:587

It says:

---
no peer certificate available
---
No client certificate CA names sent
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported

SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1703018951
Timeout : 300 (sec)
Verify return code: 0 (ok)

Is this normal? Prior to this, I had made sure that:

smtp.domain1.com was not proxied on Cloudflare (resolves to my IP)

and...

I retrieved LE certificates using the DA interface, including for smtp.domain1.com


b) Is it 'best' to set things up like this:

smtp.domain1.com
smtp.domain2.com
smtp.domain3.com

I just wanted to make sure I wasn't supposed to be using server.primarydomain.com for all domains or something like that.


Thank you

 

[Richard G]

The browser complains the certificate is not valid for the IP address.

Yes that is correct. SSL certificates are seldom issues for ip addresses mostly for domain names and FQDN hostnames and such.
If you really also want to be able to access it via IP this way, dan you have to turn the SSL=1 back to 0 in the directadmin.conf file. However, why should you do it as you can use https://server.primarydomain.com:222 and even any https://somedomain.com:2222 on the server, to be able to login as admin.

For POP, they will all obviously use for mail retrieval: server.primarydomain.com

Why obviously? DA uses by default mail.comain.com for receiving and smtp (or mail).domain.com for sending mail so for mail retrieval you should also be able to use mail.domain.com if all is correct.
However, it is also possible to use the hostname for mail, there are more hosters which do it that way.

Is this normal? Prior to this, I had made sure that:

Yes that is normal I guess. I'm seeing the same when testing on a domain on my server. But they do use SSL/TLS/STARTTLS.

b) Is it 'best' to set things up like this:

Maybe yes, you can always change later if needed. I always advise people to setup things so everything is at least working by default, and make customisations or changes afterwards. This way it's easier to detect when/where it can have gone wrong (if it would go wrong).

 

[cmyden]

Why obviously? DA uses by default mail.comain.com for receiving and smtp (or mail).domain.com for sending mail so for mail retrieval you should also be able to use mail.domain.com if all is correct.
However, it is also possible to use the hostname for mail, there are more hosters which do it that way.

Just to be sure we are still differentiating between primarydomain.com and domain1.com, domain2.com, etc.

hostname = server.primarydomain.com

For me, if I try the following:

POP3

mail.domain1.com
^^ Gmail complains: "Server returned error: "SSL error: ok Hostname "mail.domain1.com" doesn't match any SANs: "server.primarydomain.com"
^^ To note: I have no issues *sending* mail from mail.domain1.com through Gmail.

mail.primarydomain.com
^^ Gmail complains: "Server returned error: "SSL error: ok Hostname "mail.primarydomain.com" doesn't match any SANs: "server.primarydomain.com""

server.primarydomain.com
^^ Gmail is happy.


Here's what I'm currently going with in CloudFlare...


A) My understanding is that if you have an MX record of mail.domain1.com
You should also have an 'A' record that looks like the above.

If you don't remove the CloudFlare proxy for this record, the lookup for the mail server returns something like:
dc-randomstringofletters.domain1.com

After removing the proxy, the lookup for the mail server returns what is expected:
mail.domain1.com

No idea if this matters.


What I'm currently going with in Gmail...


I've tested this setup for Domain1.com with 4 testing sites (MX Toolbox, Zonemaster, LeafDNS, IntoDNS)

As well as my DKIM/DMARC/SPF settings with MX Toolbox and Mail-Tester.

I'm not getting any reports of anything being wrong, so I feel somewhat confident in going with these settings for my 10 other domains.

Unless there's something I could be doing better!

 

[Richard G]

Here's what I'm currently going with in CloudFlare...

I don't use Cloudflare, but I thought things like mail should not be proxied. I can be mistaken.
So as long as you use mail and not smtp I guess things are fine.

The complaint about SAN is not an issue as long as it's only a complaint and not an error and not refusing mail or something. But that is probably because you are retrieving mail from the hostname instead of from the domain name.
Does it also give this error if you use mail.domain1.com for retrieval? Otherwise you can better use mail.domain1.com to retrieve mail.

If you get a 10/10 on mail-tester.com and Gmail is working fine too, you should be fine.

 

[cmyden]

I don't use Cloudflare, but I thought things like mail should not be proxied. I can be mistaken.
So as long as you use mail and not smtp I guess things are fine.

The complaint about SAN is not an issue as long as it's only a complaint and not an error and not refusing mail or something. But that is probably because you are retrieving mail from the hostname instead of from the domain name.
Does it also give this error if you use mail.domain1.com for retrieval? Otherwise you can better use mail.domain1.com to retrieve mail.

If you get a 10/10 on mail-tester.com and Gmail is working fine too, you should be fine.

Sorry, yes, when I say 'complain', I mean that Gmail is refusing to proceed when setting up the account (at least in the browser client).


Retrieval / POP 3 / Port 995

mail.domain1.com
^^^ SSL error: ok Hostname "mail.domain1.com" doesn't match any SANs: "server.primarydomain.com""

mail.primarydomain.com
^^^ Unable to establish secure SSL connection to mail.primarydomain.com
Server returned error: "SSL error: ok Hostname "mail.domain1.com" doesn't match
any SANs: "server.primarydomain.com""

server.primarydomain.com Works


Sending / Port 587

mail.domain1.com Works

-

It looks like this person from 5 years ago had the same issue:

GMail G Suite Import: Unable to establish secure SSL Doesn't match any SANs

Environment: This is a new FreeBSD server. I have a customer that uses GMail G Suite to import his messages from DirectAdmin using POP3. The server has LetsEncrypt set up on it on the mail.domain.com (shared with server address) and server.serverdomain.com (which has the PTR set to...

forum.directadmin.com

Googling around, my best guess is something to do with a certificate name not matching.

 

[Richard G]

It looks like this person from 5 years ago had the same issue:

Yes he's still around.

I don't know, Gmail does odd sometimes. I presume you have a correct SSL certificate for your hostname.
Go to https://crt.sh and check for both your hostname and domain name.
Check that mail_sni=1 is present in your directadmin.conf file.

If that is all correct and you also get a 10/10 on mail-tester.com then as far as I'm concerned you're fine and it's a gMail issue.

Unless @IT_Architect was able to find a solution later on.

 

[cmyden]

Yes he's still around.

I don't know, Gmail does odd sometimes. I presume you have a correct SSL certificate for your hostname.
Go to https://crt.sh and check for both your hostname and domain name.
Check that mail_sni=1 is present in your directadmin.conf file.

If that is all correct and you also get a 10/10 on mail-tester.com then as far as I'm concerned you're fine and it's a gMail issue.

Unless @IT_Architect was able to find a solution later on.

At https://crt.sh when I try: server.primarydomain.com (my hostname) it says there were no certificates found.

I was under the impression that I had created a certificate for my hostname based on the steps that I undertook previously...
# cd /usr/local/directadmin/scripts
# ./letsencrypt.sh request_single server.primarydomain.com 4096

I remember doing this step, and it seemed to work.

And I don't think I would be able to turn on SSL=1 without it working?


In DirectAdmin -> User -> PrimaryDomain.com -> SSL Certificates
I do not have an entry for: server.primarydomain.com

Am I supposed to also create the subdomain: server.primarydomain.com

And then add it to the list of certificates to retrieve?

If I go to: https://www.ssllabs.com/ssltest//index.html
And try the certificate test for: server.primarydomain.com

It claims I do have a certificate and everything looks fine.



And also...

**

SSL Checker

Use our fast SSL Checker will help you troubleshoot common SSL Certificate installation problems on your server including verifying that the correct certificate is installed, valid, and properly trusted.

www.sslshopper.com

says...

server.primarydomain.com resolves to IP Address

Server Type: Apache/2

The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed).

The certificate will expire in 87 days.

The hostname (server.primarydomain.com) is correctly listed in the certificate.

****

Not sure why https://crt.sh can't see it.

I can confirm that mail_sni=1