Join Log in
Score:0
Vitalydotn avatar Server

SSL certificate error when not typing FQDN and relying on default search domain

tr flag
Vitalydotn

DNS and SSL aren't really in my wheelhouse more than a rudimentary understanding, I hope what I want to do isn't impossible!

Here's the situation:

  • We have an internal domain and DNS servers, let's call it inside-company.com
  • We're migrating from self-signed certs and bought a wildcard DV cert for *.inside-company.com -- This is all internal-facing so DV is sufficient
  • Most users rely on default search domain and type application/ or https://application into their web browsers instead of the FQDN

What seems to happen now to the best of my ability to tell is:

  1. Browser does DNS query and resolves IP
  2. Browser loads IP and does SSL name check
  3. Browser throws up net::ERR_CERT_COMMON_NAME_INVALID This server could not prove that it is application; its security certificate is from *.inside-company.com., I'm assuming because it hasn't re-written the URL in the address bar with the FQDN yet (and indeed the address bar still shows https://application/ at this point)

Can anything be done here? Re-educating users to use FQDN is... not really a viable option. Happens in all browsers I just gave the chrome verbiage for the error.

Also, the reason we got a wildcard cert is because there are hundreds of self-signed certs we're converting, buying one-per-application or even one-per-server would be cost prohibitive.

Thanks!

305
0 + 0
in flag
Gerald Schneider
You need a certificate that has the servername without FQDN as an SAN.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
@GeraldSchneider "You need a certificate that has the servername without FQDN as an SAN. " Which will certainly not be possible by using a public CA. That means an internal CA. The user said "bought a wildcard DB" so I guess they are using an external CA.
1
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"Can anything be done here? " The real solution, which won't please you, would be: "stop relying on search lists at the DNS level" because they will create a lot of other issues, even if they seem nice to users. Otherwise, at least if HTTP traffic (not SSL) you could possibly configure your webservers to do immediately a redirection from the short name to the new name (FQDN) and then HTTPS there. Not idea because you miss HTTPS at first step. The client does not/can not rewrite the URL as it got an IP from the DNS and just connects there and only after that can rewrite it if gotten a redirect.
1
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"buying one-per-application or even one-per-server would be cost prohibitive." You know they are public CAs delivering certificates for free?
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
You could also probably build some kind of solution using the equivalent of `wpad.dat` "configuration", that you will need to maintain for all browsers in your fleet, so that 1) all "short" names are proxied to a specific webserver you control 2) you have proper (local) certificates for all those names on this box 3) this webserver will do redirects to the full name, and the browsers will take care of everything. With however the sad consequence of potentially lots of maintenance to update the rules once you use new names (to make sure they go to the proxy).
0
Reply
Score:0
avatar Server
in flag
Gerald Schneider

You need a certificate that has the servername without FQDN as an SAN. This is the only way to prevent certificate errors when the server is accessed without the FQDN.

You can do that pretty easy by creating your own Certificate Authority (CA).

A simple CA can be created with tools like Easy RSA. After creating the CA certificate you need to deploy the CA certificate to all your clients. This is the part that is the most work, but even that can be automated (for example using Group Policies if you are using a Windows domain). After every client has the CA certificate installed and trusts it you can create any certificate you want with the CA.

Bonus: When the certificate you bought expires, you don't have to buy a new one. You can just create your own.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.