Bug 516056 - curl: no good error message for 'certificate subject name does not match target host name' error
curl: no good error message for 'certificate subject name does not match targ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: curl (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 501138 517000
  Show dependency treegraph
 
Reported: 2009-08-06 10:54 EDT by Tomas Hoger
Modified: 2009-08-31 19:43 EDT (History)
2 users (show)

See Also:
Fixed In Version: 7.19.6-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-31 19:28:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
follow-up related to comment #9 (1.59 KB, patch)
2009-08-25 06:34 EDT, Kamil Dudka
no flags Details | Diff
follow-up related to comments #9 and #11 (1.82 KB, patch)
2009-08-28 05:58 EDT, Kamil Dudka
no flags Details | Diff

  None (edit)
Description Tomas Hoger 2009-08-06 10:54:06 EDT
Description of problem:
This is probably related to NSS migration.  On Fedora 10, curl does not give me a reasonable error message in the case where certificate subject name does not match target host name.

Version-Release number of selected component (if applicable):
curl-7.19.4-6.fc10
nss-3.12.3.99.3-2.10.4.fc10

Steps to Reproduce:
Pick some https site, e.g. mail.google.com, resolve name to IP and edit /etc/hosts to map that IP to some random name (e.g. blah).  Use curl to access site using that random name.

On EL5 I get error as:

$ curl https://blah
curl: (51) SSL: certificate subject name 'mail.google.com' does not match target host name 'blah'

While on F10, less informative generic SSL verification error is used instead:

$ curl https://blah
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html

[ ... ] (long text --cacert and --insecure stripped form the report)

Not sure if this is intended, error message with more detailed information is better, of course.
Comment 1 Kamil Dudka 2009-08-06 11:24:16 EDT
Thanks for the report! There is no doubt the message could be more verbose. Nothing intended. Fedora curl was only switched from OpenSSL to NSS two years ago. I am currently working on the NSS support of curl. Feel free to report another ideas how to improve it.
Comment 2 Kamil Dudka 2009-08-10 08:07:31 EDT
Additionally discovered by Tomas that CURLOPT_SSL_VERIFYHOST is ignored by the current curl/NSS code.
Comment 3 Kamil Dudka 2009-08-13 06:55:34 EDT
patch prepared for review:
http://curl.haxx.se/mail/lib-2009-08/0106.html
Comment 4 Kamil Dudka 2009-08-13 12:16:38 EDT
amended and applied upstream:
http://cool.haxx.se/cvs.cgi/curl/lib/nss.c.diff?r1=1.51&r2=1.52

Thank Daniel Stenberg for review!

I am going to build updates for Fedora along with the new upstream release 7.19.6.
Comment 5 Fedora Update System 2009-08-14 07:03:23 EDT
curl-7.19.6-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/curl-7.19.6-1.fc10
Comment 6 Fedora Update System 2009-08-14 07:03:29 EDT
curl-7.19.6-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/curl-7.19.6-1.fc11
Comment 7 Fedora Update System 2009-08-15 04:07:07 EDT
curl-7.19.6-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update curl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8517
Comment 8 Fedora Update System 2009-08-15 04:29:40 EDT
curl-7.19.6-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update curl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8629
Comment 9 Tomas Hoger 2009-08-24 14:33:20 EDT
Error message from updated curl, noted for posterity:

curl: (51) common name 'CN=mail.google.com,O=Google Inc,L=Mountain View,ST=California,C=US' does not match 'blah'

Slightly different from openssl version (showing whole subject, not only CN, bit different wording).  Not sure if error message consistency between various SSL libraries support code is a big deal (there seem to be some differences between openssl and gnutls wrapping too).  Without that concern, this message should be good enough, imo.
Comment 10 Kamil Dudka 2009-08-25 06:34:46 EDT
Created attachment 358551 [details]
follow-up related to comment #9

Good point. Please look at the attached patch. I am going to apply it upstream. Unfortunately curl.haxx.se seems to be down right now.
Comment 11 Tomas Hoger 2009-08-25 11:00:52 EDT
(In reply to comment #10)
> Good point. Please look at the attached patch. I am going to apply it upstream.
> Unfortunately curl.haxx.se seems to be down right now.

The patch seems to do whole subject -> CN change for error message.  So we don't care about error message consistency?  These are messages currently printed:

ssluse:

  if(data->set.ssl.verifyhost > 1) {
    failf(data, "SSL: certificate subject name '%s' does not match "
          "target host name '%s'", peer_CN, conn->host.dispname);
    res = CURLE_PEER_FAILED_VERIFICATION;
  }
  else
    infof(data, "\t common name: %s (does not match '%s')\n",
          peer_CN, conn->host.dispname);


gtls:

  if(data->set.ssl.verifyhost > 1) {
    failf(data, "SSL: certificate subject name (%s) does not match "
          "target host name '%s'", certbuf, conn->host.dispname);
    gnutls_x509_crt_deinit(x509_cert);
    return CURLE_PEER_FAILED_VERIFICATION;
  }
  else
    infof(data, "\t common name: %s (does not match '%s')\n",
          certbuf, conn->host.dispname);


(the two above are almost identical ;)


nss:

  if(conn->data->set.ssl.verifyhost) {
    failf(conn->data, "common name '%s' does not match '%s'",
          subject_cn, conn->host.dispname);
    success = SECFailure;
  } else {
    infof(conn->data, "warning: common name '%s' does not match '%s'\n",
          subject_cn, conn->host.dispname);
  }


Yeah, just nitpicks... ;)
Comment 12 Kamil Dudka 2009-08-28 05:15:49 EDT
(In reply to comment #11)
Sorry, I've overlooked the note about error message wording. If I understand, you want to get the same error message as with the OpenSSL curl, right?

I am only not sure with the info message starting with "\t". NSS variant displays server's certificate only after successful handshake (in contrast to OpenSSL). Do you want to change this behavior as well? Or will be only the change of the error message sufficient for you?
Comment 13 Tomas Hoger 2009-08-28 05:38:30 EDT
(In reply to comment #12)
> (In reply to comment #11)
> Sorry, I've overlooked the note about error message wording. If I understand,
> you want to get the same error message as with the OpenSSL curl, right?

Not sure if I *want*, I just noticed the difference.  And as you are changing that code already, wouldn't it make sense to have the same error message for the same error condition, regardless of the crypto library in use?

Of course, I have no problem with "wontfix" as an answer if the differences are desired or hard to avoid (e.g. because of briefly mentioned \t difference issue).  From user pov, using the same (as similar as practical) messages for same problems seems like the "right thing".  That's all.
Comment 14 Kamil Dudka 2009-08-28 05:58:14 EDT
Created attachment 359042 [details]
follow-up related to comments #9 and #11

It makes sense to me. Are you fine with the attached patch?
Comment 15 Tomas Hoger 2009-08-28 06:14:06 EDT
(In reply to comment #14)
> Created an attachment (id=359042) [details]
> follow-up related to comments #9 and #11
> 
> It makes sense to me. Are you fine with the attached patch?  

Looks good from a quick look.

You can always ask upstream how much they care about wording consistency when submitting this patch...

Thank you!
Comment 16 Daniel Stenberg 2009-08-28 07:23:49 EDT
Speaking for upstream:

We don't particularly need or aim for wording consistency in the error messages. But I'm also not against making them more similar as I'm sure it'll benefit users in the end.

The current standpoint is mostly due to pragmatic reasons (== nobody has tried to unify the SSL lib error messages).

We do however make an effort to make the APIs and ABIs the same, unregarding of which actual lib is used, so the actual return codes are considered very important to remain the same all over.
Comment 17 Fedora Update System 2009-08-31 19:28:38 EDT
curl-7.19.6-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2009-08-31 19:43:38 EDT
curl-7.19.6-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.