4

I am trying to send a cURL request to a server with an IP address x.x.x.x . It is a part of an health monitoring system. On the server I have configured virtual hosts for subdomain.example.com on both port 80 and 443. For the ssl certificate, I am using a *.example.com wildcard certificate which I use on this server as well few more servers.

When I try to curl to http://x.x.x.x it get the response appropriately. But when I curl to https://x.x.x.x it give the following certificate error:

curl: (51) SSL: certificate subject name '*.example.com' does not match target host name 'x.x.x.x'

I know this is because certificate is specific to domain name and I am trying to send a request using the IP address. But as I said this is a limitation that I have (rackspace load balancer health monitoring).

Is there a work around??

Ankit Khedekar
  • 145
  • 1
  • 1
  • 5
  • 1
    You can't unless you add the IP address of the server as a SAN (Subject Alternate Name) which I'm not sure is an option for you as it involves modifying the certificate itself. – Nathan C Jul 15 '14 at 13:24

2 Answers2

10

You can use the domain name as usual but override the resolver like so:

curl -v --resolve subdomain.example.com:443:x.x.x.x https://subdomain.example.com/

It might be awkward to maintain a lot of such mappings though. You might prefer to just ignore the cert mismatch:

curl --insecure https://subdomain.example.com/

IF you want, you could use --insecure --verbose and parse the messages to check that the cert is for the expected domain, but that's probably more work than using --resolve

mc0e
  • 5,786
  • 17
  • 31
  • I am aware of the -k flag, but modifying the cURL request is not a option, because it is handled by some other appplication and is not configurable. Hence I was asking for a work around that can be done on the server – Ankit Khedekar Jul 15 '14 at 13:10
  • Is cURL even involved then? In that case the answer is most likely specific to the server that rackspace is running. Maybe you should ask them? – mc0e Jul 15 '14 at 13:34
  • as I mentioned before, the actual appplication that is making the curl request is not in my control. It is a rackspace application. so i cannot add flags/params to the curl request – Ankit Khedekar Jul 15 '14 at 13:35
  • If you're asking whether there's a server side workaround that can serve an SSL compliant response, while being requested via a IP address in the host header, then the answer is probably no. Maybe you could use an alternative cert, but I'm not sure how you'd get it signed such that the rackspace monitoring would accept it without some intervention in that configuration beyond the URL. – mc0e Jul 15 '14 at 13:37
  • Yes somewhat, actually the other way. The server should serve SSL compliant respone when being request using IP address in the URL. I also tried setting Host header in the request to a valid domain something like `curl https://x.x.x.x -H "Host:subdoamin.example.com"`. Even this doesnt work. – Ankit Khedekar Jul 15 '14 at 13:59
  • 1
    Actually setting the host header does work in terms of getting curl to construct the query correctly, but curl then compares the certificate with the hostname in the url, not the one in the header provided with '-H'. – mc0e Jul 15 '14 at 14:05
  • @AnkitKhedekar The error listed in the question suggests that the server responds just fine but that the client deems the certificate invalid. If you can't change things on the client side (`curl` command line or possibly some `hosts` file entry) I think you'll need a certificate that actually lists the IP address. – Håkan Lindqvist Jul 15 '14 at 14:15
  • @HåkanLindqvist ok thanks. Since all this is on a cloud load balancer I dont have much control. Will adding a reverse DNS record help? – Ankit Khedekar Jul 15 '14 at 14:25
  • @AnkitKhedekar No, it's simply a matter of that the certificate presented by the server must match what the client thinks it is connecting to, otherwise the client will abort with an error. – Håkan Lindqvist Jul 15 '14 at 14:27
  • 1
    If you wanted to be insane, you could modify /etc/hosts so that the FQDN in question pointed directly to that specific IP. That would make your curl command work properly, but would probably break everything else. If you wanted to double down on crazy, I suppose you could couple that with a `chroot` jail, so that just that application gets the wacky /etc/hosts. – Christopher Karel Jul 15 '14 at 15:51
4

I'll make this a new answer, since it's going in quite a different direction. In fact it doesn't answer the question as posed, but is perhaps the direction the OP should be looking.

The usual configuration when using a load balancer is that the SSL certificate doesn't live on the web server at all, but rather the SSL is handed off to the load balancer.

The end user makes an HTTPS request to the load balancer. The load balancer unwraps the SSL, and forward the request via unencrypted HTTP to the web server, with a header that tells the Web server that the original request was encrypted. (important for embedding URLs in the response, and for avoiding serving secure content over http).

mc0e
  • 5,786
  • 17
  • 31