1

I am trying to establish server client communication over SSL using self signed certificates. On server side, I added CN= while creating certificate. My Client is communicating using libCurl with CURLOPT_SSL_VERIFYPEER set to 1 and CURLOPT_SSL_VERIFYHOST set to 2.

When client tries to send request using server's FQDN in URL, it works fine. but if client uses IP address instead, I am getting error message as 'SSL: certificate subject name '' does not match target host name ''' I understood the problem is 'Hostname used in url should match with subject name' provided in certificate.

But what is the solution to this problem? Client should be able connect using IP address/short hostname/FQDN. I tried adding multiple CN entries(for FQDN and IP) in certificate but it didn't work.

user2078670
  • 43
  • 1
  • 5
  • 2
    DNS names should *not* be placed in the Common Name (CN). That behavior is deprecated by both the IETF and the CA/Browser Forums. Instead, use a friendly name in the CN because its displayed to the user. DNS names should be placed in the Subject Alternate Name (SAN). That is specified by both the IETF and CA/B Forums. *Note*: the CA/Browser Forum is important because that's where browsers and CAs get together and decide policy. Browsers follow the CA/B Forum, and do not follow IETF recommendations. – jww Dec 25 '14 at 23:56

1 Answers1

5

Use the real host name in the URL to libcurl so that the host name verification works.

If you want to point to another host than what that name normally would resolve to, use CURLOPT_RESOLVE to force libcurl to use your local/temporary IP instead.

See the resolve.c example on how it can be done.

If you want to add multiple names in the certificate, you use the SubjectAltName instead of CN.

Daniel Stenberg
  • 54,736
  • 17
  • 146
  • 222
  • I am using OpenSSL v5.0.8.1 and there seems to be a vulnerability for using SubjectAltName in certificates https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4248 for OpenSSL v < 5.5.2. Is there any other alternative way apart from upgrading OpenSSL version? – user2078670 Dec 16 '13 at 07:01
  • That CVE refers to PHP versions, not OpenSSL. The vulnerability is really in PHP. That flaw does not exist in current libcurl, but it did suffer from a similar one that we fixed back in 2009: CVE-2009-2417: http://curl.haxx.se/docs/adv_20090812.html – Daniel Stenberg Dec 16 '13 at 07:45