Google has just started to encourage end-to-end signing/encryption of email by displaying a little red broken lock icon on e-mails which don’t meet this requirement.
I would like to use my domain’s LetsEncrypt certificate to digitally sign e-mails sent thru the SMPT server. As I understand it, what Google would like, is that as well as the sender’s connection to the SMPT server be signed/encrypted (using STARTTLS), it would like the email to be signed/encrypted as it is forwarded until it reaches Google’s servers (otherwise a little red broken lock is displayed on the gmail page).
Can my LetsEncrypt certificate be used for this, or do I have to use [maybe purchase] a certificate from some other authority?
I’ve read somewhere that the LetsEncrypt certs can’t be used in this way, but that may just be random web noise. Can someone authoritatively give an answer and explain what is the issue (if there is one).
RobinE
what “new signing requirement” by google is this ? can you provide a link please ?
I’m assuming you don’t mean DKIM, but are referring to some other encryption / signing ?
LE certs can be used for this for TLS connections between servers, what they can’t be used for is as client certs to sign and encrypt the contents of the email itself.
If you have a gmail, mail account open (on the web) any received e-mail to see a small icon at the top left of the message. It was introduced about two weeks back. Hover over the open lock to have Google tell you what’s upsetting them.
If you have a gmail, mail account open (on the web) any received e-mail to see a small icon at the top left of the message. It was introduced about two weeks back. Hover over the open lock to have Google tell you what’s upsetting them.
Does this only appear with "problem" emails ? I can't see any small icon, top left that shows an issue on any of my emails in gmail (maybe all mine are good, so it doesn't show ? )
There’s a gmailblog entry that announced it on “Safer Internet Day”:
To make gmail happy (I just tested - it likes my mailservers), two things need to be present:
First, there must be STARTTLS on the outgoing MX. While the LE certs do say ‘web server auth, web client auth’, no MX appears to be picky about it, and will accept the cert for SMTP regardless.
Second, there needs to be an SPF record in DNS for the source email domain. I have a TXT record with ‘v=spf1 a mx ?all’ and this is enough (itranslation: all servers that can receive mail for the domain can also send. Other adresses: neutral, treat as unauthenticated).
Google also seem to be happy with using self-signed certificates on outgoing SMTP connections.
well if you use a proper SPF policy it might already give you a nice boost because as email is TCP, the sender’s IP cannot be faked and with a -all you kcik out everyone for you email who is not listed before.
I use this policy (which works well if you only need your web and MX server to send emails.
v=spf1 mx a -all
this inside a txt record and you have a well-working pretty strict SPF record.
if you only want your MX to send emails, remove the a part.
? mark is pretty neutral which probably gives a better treatment that ~ (bad, but dont treat that that bad, e.g. dont reject but mark the message, usually used for debugging) I would prefer ~ over ? especially if you dont need to send from others, where - is even better sinc mails from minus’ed servers can be sent directly into oblivion, /dev/null whatever you want to call it, which is especially helpful against prople trying to pose as an email for your domain.
it is really hilarious, in a BAD way when BANKING or PAYMENT providers use ~ for their SPFs (like paypal or the German Sparkasse) and even worse when they have ? (deutsche bank) it would be nice if there would be an email client which tell us how restrictive the SPF entries are for a given domain, so we can see how trustful their emails are.