0

I am new to HTTPs and want to have my web application on secure ports. For this, I asked our security department to issue certificates. And I provided them with the CSRs. The CSRs were generated on FQDNs which are not there in the URL.

For example, FQDN against which the CSR was generated was mywebappserver whereas the URL (which has to be changed to secure port and HTTPs is http://hostname.domain.lan:8080/mywebapp.

My colleague told me that he can set up the HTTPs by adding those certificates but browser will show a warning. Because certificates are generated on an FQDN which is not part of the URL.

Can I have some DNS routing, like: customer will access https://hostname.domain.lan:8443/mywebapp and this will redirect to https://mywebappserver:8443/mywebapp but in browser still customers see https://hostname.domain.lan:8443/mywebapp

Objective is to keep communication over HTTPs without any warning in browser. Is it possible?

PS: I can't get certificates again with correct FQDNs.

Tahir
  • 103
  • 2

1 Answers1

1

Can I have some DNS routing, like: customer will access https://hostname.domain.lan:8443/mywebapp and this will redirect to https://mywebappserver:8443/mywebapp but in browser still customers see https://hostname.domain.lan:8443/mywebapp ... without any warning in browser.

No, that's straightforwardly impossible. The whole point of the subject name (either Common Name or Subject Alternate Name) in the certificate is so that the client (the web browser, in this case) can verify that the certificate is for the site the client thinks it is connecting to. This is explicitly to prevent the kinds of DNS shenanigans you're describing (among other things).

An example of why this obviously won't work: suppose I own cbhacking.com. I get a valid certificate for it. Then I decide one day that I'd like to steal all of your traffic, so I spoof responses to your DNS queries (DNS is plain text, and usually not even signed, it's easy to spoof if you're on the same network and possible even if not) and any time you request gmail.com or stackexchange.com or mywebappserver or whatever you get my server's IP address. My server serves you the certificate for cbhacking.com because it's the only valid cert for which I have the private key. Clearly your browser needs to complain about the name mismatch (it thought it was going to gmail.com; it got a cert for cbhacking.com), though!

To address your internal problem, have you considered just setting up the server on an internal host called "mywebappserver" (or naming the internal server mywebappserver in addition to / instead of hostname.domain.lan)? Assuming it is in fact an internal host the way it looks like it is, and that your internal DNS is OK with serving responses to raw hostnames rather than FQDNs (most are), this will work fine. You'll need to give people the new URL, but that can be done with a redirect (HTTP 301 or similar) from the old name to the new one.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • Ok so I think I have two ways to solve this problem: 1) I set up my application URL like this: https://mywebappserver:8443/mywebapp so that certificate and URL get handshake and browser dont show warning. And then I use some DNS redirect to make the traffic redirect to https://hostname.domain.lan:8443/mywebapp. This feasible? 2) I get a new certificate with the correct CSR generated on FQDN: hostname.domain.lan and install it on the web server so I keep the URL: https://hostname.domain.lan:8443/mywebapp. – Tahir Dec 08 '21 at 08:24
  • Well, if you make the DNS entry for mywebappserver point to the IP of hostname.domain.lan, then that server now has two domain names. That's what a domain name *is*, after all: the name[s] that point to your IP in a DNS server. So yes, that would solve it. But people would have to see https://mywebappserver in their browser URL bar, or they'll get an error (unless you get a new certificate). – CBHacking Dec 08 '21 at 10:52