Hi, we have an on-premise SBS2011 box running our Exchange Server 2010. Now up until recently when all the staff updated iphones to iOS 13, there are new restrictions in place for certificates etc so everyones emails have dropped off.
This is a new subject for me so i’m not sure what to ask to get the right answer.
We have been using self signed certificates generated by the server itself using ‘fix my network’ so my interaction with certificates is nil to minimum.
I would like to create a SSL Certificate for our on premise server for remote.vseal.co.uk which at the moment fails with an F using the SSL Server Test.
If we log in from a browser, we can go to https://remote.vseal.co.uk/owa which is our main page, this offers a warning and pretty much states non-trusted.
I have installed and started the process of CertifyTheWeb and the test passes with ticks down the list, but when I request a certificate I get a warning stating there is a timeout with possibly a firewall issue…
Is it possible you already resolved this another way? It looks like that domain has a 24 month cert from RapidSSL that was added yesterday. I’ve heard that some clients will stop trusting long-duration certificates… but this one is still in the first week of deployment, so I don’t think it would be considered bad.
Anyways, since the domain seems to be handled by IIS, CertifyTheWeb should be able to step in and handle requests… but I’m not sure about the firewall problem as it seems accessible from the eastern US.
The bad grade on SSL checkers is mostly because your server supports ancient encryption… even though it also supports newer encryption. Most clients will use the best it can… so I never understood why it kills the rating so hard. I guess removing support for everything below TLS 1.0 will raise your rating considerably. Current recommendations are to remove support for anything below TLS 1.2, but for some people it’s not feasible due to certain clients.
It looks like the issue was that you block port 80 on your server. Let’s Encrypt performs http validation by checking for a chllange response on http port 80 (the server can then redirect to https etc but it needs to answer on port 80.).
For anyone with a similar issue getting started, open port 80. You can test this by trying to telnet to your server on port 80 (for instance) using a connection outside your network (like your mobile phone wifi hotspot).
I just realised the docs page for http validation doesn’t mention this, so I’ll update that. The error message and log should report the exact url that’s inaccessible though.
Hi, in all cases when using a single certificate the certificate must include all of the fully qualified host names that people will connect with. You can add multiple hostnames to a certificate.
So if users might connect as either webmail.vseal.co.uk and mail.vseal.co.uk for instance then all of these names must be on the certificate. If they connect using an intranet local name (like just ‘webmail’) then you need to change that as local names can’t appear on a certificate issued by Let’s Encrypt (or any public certificate authority).
My question extends into failing a PCI scan where there is an issue with the banner on smtpd, having seen some fixes on the net where I need to populate this field with something, I’m not sure ‘what’ I should put in there in case it breaks something else. On that note, if I add something to this banner, will it change what is required on the cert?
Do I need a second cert for local email access on our server?
Apologies this is where my inexperience is showing again.
Typically a communication with an SMTPD goes like this:
Server: 220 mail.domain.com ESMTP
Client: EHLO clientname
Server: 250-COMMAND2 (etc)
Server: 250 HELP
Then the client uses one of the commands listed in the 250 response block to authenticate or send a mail.
The banner you’re speaking of may be the name listed in the 220 message or 250 message, I’m not sure. But likely the name needs to match the name in the certificate. There’s probably a setting that tells the server what FQDN it should identify as rather than manually adding flavor text to the banner.
Local email access should just use the external domain name like external users do. Routers should be smart enough to route the traffic back in before it enters the internet. If not, you could mess with it and add a static route… or create a DNS entry on your (hopefully local) DNS server to route the mail subdomain to the LAN IP.
Thank you @jljtgr. There is still a lot I need to understand.
I know the tutorial on one of the things to do with the smptd banner for PCI is to do with the 220 and setting the banner to match the cert which would make the banner 220 remote.vseal.co.uk (I think??) but like I say I don’t fully understand it and don’t want to break anything. I’ve been doing cleanup on our server so I can get a pass, but sadly i’ve found a broken a connection from a program that syncs with our server and a few folk are complaining they can’t slide emails into folders in Outlook.
Yes, anything that references a server name (and configuration the client sees) has to be using the name that’s on the certificate.
I’m not an exchange administrator, any online guide for Let’s Encrypt and MS exchange should tell you what to update though.
With a certificate your are saying this service is for ‘remote.vseal.co.uk’ (or any other names on the certificate). When you acquires the certificate from a certificate authority you validated that you control that domain/subdomain, that’s why they were able to give you a certificate for that domain.
The problem with local intranet names is you could happily call your server anything and no certificate authority can say whether you really control that server or not. So if you need a cert for a local name (like ‘exchange01’ or ‘webmail’) you need to self sign the certificate and have your client machines trust it. Basically not worth it.
Hey, I had some past experience with Exchange and SBS servers in particular - I’m guessing what you’re running into is going to be with Exchange 2007-2019’s ‘autodiscover’ service. If you’re seeing a different site name that’s not Autodiscover, then ignore what I’m saying and something different is going on.
Autodiscover works in the background to help with automatic configuration based on the email account’s domain name. Exchange and its clients in general are expecting at least 2 different hostnames, both of which need to be trusted with a single certificate on your SBS box. Those Outlook prompts you’re seeing would be because the clients are likely trying to hit ‘autodiscover-’ without telling you - the SBS server presents them with the certificate only allowing for ‘remote-,’ and mismatch!
If that’s what you’re seeing, whatever SSL certificate you implement probably needs to cover at least “remote.vseal.co.uk” and “autodiscover.vseal.co.uk.” It’s often referred to as a UCC certificate (Unified Communications Certificate), and that’s mostly branding - they’re usually a ~5 hostname SAN certificate intended specifically for Exchange without being a full wildcard cert, but you’d only need 2-3 hostnames.
Even shorter version, I suspect that just using Certify and sorting out getting both domains on one certificate would probably work too. If you’re researching the how and why on your own, I’d try ‘exchange ucc certificate,’ ‘exchange san certificate,’ or terms like that.