I am trying to install Let’s Encrypt certificate for this domain. This domain is with me only for email hosting and its website is hosted somewhere else.
Can this work ? Or do i need to add my email server’s NS records at this domain’s registrar ?
Hi Schoen,
You are absolutely correct this is precisely what i am trying to achieve and there are server other domain which i am planning to implement this same concept.
I have access to its Domain Control Panel, i tried adding name server for my mail server but what happens is that website goes down and the website starts pointing to the mail server instead.
So, there are three methods that Let’s Encrypt uses to let you prove your control over a domain name in order to get a certificate for it. Two of them require making a connection to your server, which is not helpful when your server is run by someone else. The third requires posting custom TXT records in your DNS zone (not changing the existing records, but adding new additional ones). Can you do this? It would be easiest if you could do it via an API or script rather than manually, because this would then leave open the possibility that the certificate can be renewed automatically in the future.
The acme.sh client currently has the broadest range of support for DNS provider APIs. The supported ones are listed at
Recently Certbot has also added some of this support, but not quite as much as acme.sh has.
As @ahaw021 mentions, you do have to prove control over the domain name in order to get a certificate. While being the mail server (indicated by MX record) for a domain is an important relationship with that domain, it’s not one that Let’s Encrypt accepts by itself as enough to issue a certificate for the domain. Other certificate authorities might have a different practice because they do e-mail based validation, which Let’s Encrypt never does. For Let’s Encrypt certificates, the only available ways to prove your control are to receive inbound connections on port 80 or 443 (of the machine that the A record for the domain points to, which is also then the web server for that domain), or to make changes to the DNS zone. If you can’t do these things, Let’s Encrypt will not accept that you’ve proven that you’re entitled to a certificate for a particular domain name—even if you do run the mail server for it.
There is a particular thing that people running the mail server could do (involving setting up a web redirect for a particular URL) to explicitly delegate the power to obtain certificates for their domains to you, from Let’s Encrypt’s point of view. So this is an additional option if you have the ability to coordinate with them this way; they wouldn’t have to make your machine the web server or give you the ability to edit the DNS zone, if they’re willing to forward some particular Let’s Encrypt-related URLs from their server to yours via web redirects.
Thanks guys my only intention is to secure mail.domain.com or just smtp/pop/imap for which i am planning to ask my users to add A record for mail.domain.com and a txt record for mail server IP. Is this sufficient ? Coz i have no interest in the TLD i just want that every user uses mail.domain.com for his/her email client configurration amd in orde ! to do that this subdomain should be secured.
If you use mail.domain.com for everything and you don’t need the certificate to cover domain.com, then getting an A record for mail.domain.com should be fine. Then you should be able to get the certificate for that domain by yourself without other coordination with the people running the domain.
The same certificate will work for all of these protocols, but the A record is only used by clients to decide where to connect for POP and IMAP. For SMTP, clients use the MX record to decide where to connect.
ACME is the protocol used to talk to the certificate authority. It defines three different challenges, HTTP-01, TLS-SNI-01, and DNS-01. Which challenge type where you using? Which command did you run?
But I thought that @rohanb105 was now trying to get the certificate only for the mail.domain.com subdomains, which presumably will already have an A record because that is necessary for the clients to connect to them.