AnsweredAssumed Answered

Question about Wildcard Certificates

Question asked by Adam Marcionek on Jan 12, 2015
Latest reply on Mar 14, 2018 by Aleksandr Rainchik

Hi there,


We have an HCP virtual appliance used for testing which uses the default self-signed certificate.  When you look at the certificate, it contains *.[system FQDN] which makes sense. One problem we have, however, is using this with libCurl.  When connecting to the tenant (e.g., using MAPI) that certificate passes libCurl's checks.  However, when connecting to the namespace (e.g. reading and writing data) that certificate fails. 


When I look up the way wildcard certificates are supposed to work, I'm getting mixed results.  In some cases, however, it appears that a wildcard only applies to one subdomain off the root domain. E.g. [tenant name].[system FQDN] would pass a name match but [namespace name].[tenant name].[system FQDN] would not. See reference 2 here: I should note that this problem only started occuring after upgrading our libCurl version to 7.39.0 from 7.23.1 so it appears that some backwards incompatible change has occurred in libCurl. However, if it is acting as it should, it would be a tough sell back to the community to change itself.  I should also note that it appears functionality using IP addresses and name matching in libCurl has also been changed (via cURL - libcurl IP address wildcard certificate validation)


You can, of course, bypass host name checking by using curl_easy_setopt(hCurl, CURLOPT_SSL_VERIFYHOST, 0L) but that's a fairly insecure method. My question is if this issue has been seen in the field and what to do about it?


Best Regards,

Adam Marcionek