Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question
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 Answers 2

up vote 2 down vote accepted

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

share|improve this answer
That is, you suggest ssl termination at the load balancer itself? –  Ankit Khedekar Jul 16 '14 at 12:32
@AnkitKhedekar See my answer to your other question for how to do so: serverfault.com/a/613232/20148 –  phoebus Jul 17 '14 at 5:34

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

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.