> To put it another way, you need to think about this backwards. Rather
> than 'How can I make curl pass a particular HTTP 1.1 request host in its
> headers when accessing server X?', you just pass the HTTP 1.1 host you
> want in the URL and use Daniel's answer to answer the question 'How can
> I make curl look up a particular HTTP 1.1 request host as X rather than
> Y so the request goes to the right server?'.
>

I believe that the misunderstanding lies in the fact that you see this as
a separate "issue". The point is that this is not a different
topic from the initial certificate Issue, which lead me to the feature
request (proposal), so we should not separate both.

Let's put it into a practical way to sync it again:

Take the following as given:

1) Hoster is hoster.com, which is mapped to IP 1.1.1.1
2) My domain is mydomain.com served by a single server 2.2.2.2
3) The hoster does only have a certificate for *.hoster.com for all his servers
4) I have 2 virtual servers running on my server (i.e. 2.2.2.2) called site1.mydomain.com and site2.mydomain.com (both at the standard ports)

So if someone accesses site2.mydomain.com he will get presented with a *.hoster.com certificate that does not match.

Solution 1:

  --resolve site2.hoster.com:443:2.2.2.2 https://site2.hoster.com/

  This request will validate the certificate correctly, but fail to match the virtual server

Solution 2:

  https://site2.mydomain.com/

  This will match the virtual server but fail the certificate (requiring the insecure option)

Solution 3 (not discussed so far):

  I guess with current possibilities it is still possible using:

  --resolve site2.hoster.com:443:2.2.2.2 --header Host:site2.mydomain.com https://site2.hoster.com/
 
  This will match both the virtual host via the altered header and the certificate as long as the internal testing is not done against the same as the host header.

Solution 4 (my proposal):

  --alternate-cert-host site2.hoster.com https://site2.mydomain.com/

  This will work like solution 3, as the certificate is matched against the option, with 2 major advantages:

    - Better readability and easier use
    - Normal resolver processing for the addresses (including multiple addresses)

So yes it can be done, with the drawback that only one address is taken into account or external processing is required to try them all.

I want to make clear that in my current application I don't require this (as in my case --resolve with a single address works fine as there is only one address). So I am not trying to defend my cause, but I think that an extra option for an easy solution for a very common problem without needing any processing knowledge would be a good point.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-04-24