5

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??

Improve this question
1
  • 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, 2014 at 13:24

2 Answers 2

Reset to default
5

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).

Improve this answer
2
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

Improve this answer
10
  • 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, 2014 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, 2014 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, 2014 at 13:35
  • 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, 2014 at 14:05
  • 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, 2014 at 15:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .