# Understanding server name resolving vs Host headers in HTTPS **URL:** \ **Category:** Help\ **Created:** [June 9, 2024, 10:31am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784 "2024-06-09T10:31:56Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![hyperknot](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/hyperknot/32/37907_2.png) [@hyperknot](https://community.letsencrypt.org/u/hyperknot)\ **Post date:** [June 9, 2024, 10:31am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/1 "2024-06-09T10:31:56Z")
I'm trying to understand why does curl resolving vs Host header works for HTTPS websites. My problem is the following: For HTTP, these two are exactly the same: ```nohighlight curl -I http://direct.openfreemap.org/styles/liberty ``` and ```nohighlight curl -H "Host: direct.openfreemap.org" -I http://144.76.168.195/styles/liberty ``` however, for HTTPS, there is no way to make it work. ```nohighlight curl -H "Host: direct.openfreemap.org" -I https://144.76.168.195/styles/liberty curl: (60) SSL certificate problem: self signed certificate More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. ``` The only way to make it work with HTTPS is to use the special, low-level "resolve" option with curl: ```nohighlight curl --resolve direct.openfreemap.org:443:144.76.168.195 -I https://direct.openfreemap.org/styles/liberty ``` My problem is that while it works with curl, I cannot do the same in a JS environment, for example in a Cloudflare worker. I'm trying to use Cloudflare workers to health-check individual servers behind a Round-Robin DNS record, and this would be the only way. Can you tell me how does HTTPS work, or how can I possibly fix this? The "Host" header is definitely not enough. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [June 9, 2024, 10:43am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/2 "2024-06-09T10:43:03Z")
> [@hyperknot](#): > > The only way to make it work with HTTPS is to use the special, low-level "resolve" option with curl Not for me. Curl works perfectly with HTTPS: ```nohighlight osiris@erazer ~ $ curl -I https://direct.openfreemap.org/styles/liberty HTTP/2 200 server: nginx date: Sun, 09 Jun 2024 10:41:37 GMT content-type: application/json content-length: 42425 last-modified: Fri, 31 Dec 1999 23:00:00 GMT etag: "386d3570-a5b9" expires: Mon, 10 Jun 2024 10:41:37 GMT cache-control: max-age=86400 access-control-allow-origin: * cache-control: public osiris@erazer ~ $ ``` I also don't get any "self signed certificate" error, there seems to be a Let's Encrypt certificate configured. Can you perhaps say more about what you're trying to do and why you need all those "Host" headers to begin with? ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [June 9, 2024, 10:49am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/3 "2024-06-09T10:49:36Z")
> [@hyperknot](#): > > `curl -H "Host: direct.openfreemap.org" -I https://144.76.168.195/styles/liberty` This has nothing to do with this forum. It is expected: ![image](https://global.discourse-cdn.com/letsencrypt/original/3X/7/5/755ae3a043c2b0c747779c99fb2fb5f28b27fb3c.png) The `-H` header is NOT for HTTPS. Why are you using an IP in the URL instead of the name on the cert? If the name doesn't resolve to that IP, then you can override it locally in the `/etc/hosts` file. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [June 9, 2024, 10:51am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/4 "2024-06-09T10:51:35Z")
headers, host or whatever it will be is http layer thing, and TLS layer ignores it: if you call curl by IP address it will send request with any server name indication, so server have to return default certificate that's likely not valid for your expected name ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [June 9, 2024, 10:53am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/5 "2024-06-09T10:53:08Z")
he said he wants to connect to specific backend server from few round robin servers in DNS ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [June 9, 2024, 10:59am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/7 "2024-06-09T10:59:02Z")
Then instead of -H, he will have to do something else. I proposed overriding DNS. [there are other solutions] A simpler solution is to provide [additional] unique names and certs to each backend. None-the-less, the topic text and first post make the request clear: _"I need help understanding `cURL` with `HTTPS`."_ This is not a forum for that. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [June 9, 2024, 11:08am UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/8 "2024-06-09T11:08:58Z")
Maybe it's as simple as a SNI issue. As far as I can tell from `man curl`, the `-H Host ...` option does not change anything with relation to the SNI value. Thus a `curl` command with the `https://hostname/` is required to set `hostname` as the SNI value and if OP then needs to do some fancy resolving using `--resolve` due to their internal shenanigans, well, that's just that 🤷🏻‍♂️ Maybe OP needs to Google/DuckDuckGo/ChatGPT with keywords `sni` and `javascript` to fix their JS environment, I dunno.. Maybe it's as simple as using and setting `tlsSocket.servername` in their Node.js (assuming they're using Node.js) script 🤷🏻‍♂️ Or maybe set the `hostname` property/context with `server.addContext()`, I dunno, I don't "speak" Node.js.. There are 17 mentions of `sni` on [TLS (SSL) | Node.js v22.2.0 Documentation](https://nodejs.org/api/tls.html#alpn-and-sni), so probably enough to read about. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [June 9, 2024, 3:42pm UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/9 "2024-06-09T15:42:10Z")
> [@hyperknot](#): > > I'm trying to use Cloudflare workers to health-check individual servers behind a Round-Robin DNS record, and this would be the only way. I don't have any new insights into how to setup SNI with js. But, do you have to use HTTPS for the health check? Wouldn't an HTTP endpoint be sufficient to know if the backend server is responding? FWIW, openssl can set SNI separately as well: ```nohighlight openssl s_client -connect 144.76.168.195:443 --servername direct.openfreemap.org ``` ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [July 9, 2024, 3:42pm UTC](https://community.letsencrypt.org/t/understanding-server-name-resolving-vs-host-headers-in-https/219784/10 "2024-07-09T15:42:11Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.