1164328 – svn & gnutls not working as expected with sha2 certificate

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1164328 - svn & gnutls not working as expected with sha2 certificate

Summary: svn & gnutls not working as expected with sha2 certificate

Keywords:
Status:	CLOSED NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	gnutls
Sub Component:
Version:	6.4
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Nikos Mavrogiannopoulos
QA Contact:	BaseOS QE Security Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2014-11-14 16:49 UTC by jstephen
Modified:	2018-12-09 19:10 UTC (History)
CC List:	1 user (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2014-11-20 15:26:31 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description jstephen 2014-11-14 16:49:19 UTC

Description of problem:

The rhel6 svn app which is linked with gnutls does not recognize a sha256 certificate.  OpenSSL based apps (like wget) have no problem with the same certificate. e.g.,
wget --user=ric --ask-password https://subversion.uits.arizona.edu/ops/infradevtools/account/trunk
works without complaint, but
 svn list https://subversion.uits.arizona.edu/ops/infradevtools/account/trunk
says
Error validating server certificate for 'https://subversion.uits.arizona.edu:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: subversion.uits.arizona.edu
 - Valid: from Wed, 05 Nov 2014 00:00:00 GMT until Sat, 04 Nov 2017 23:59:59 GMT
 - Issuer: InCommon, Internet2, Ann Arbor, MI, US
 - Fingerprint: d5:2a:4d:19:04:d7:2f:c1:7e:ce:a0:dd:3e:7d:75:88:a9:0f:d5:71

This has been reported on debian as well, https://bugs.debian.org/737921

Obviously I can accept the cert, but I'd rather not have to do that.  

tools that use OpenSSL (such as the RHEL5 svn and openssl s_client) have no problems with the SHA2 certificate on my subversion server.
tools that use GNUtls 2.x (like RHEL6 svn and gnutls-cli) reject the SHA2 certificate, but both work with an older (pre-SHA2) certificate.
tools that use GNUtls 3.x (like RHEL7 svn) have no problems with the SHA2 certificate on my subversion server.

Is there a backport of GNUtls 3.x I could slide in to my RHEL6 client systems to resolve this problem?

Version-Release number of selected component (if applicable):
gnutls

How reproducible:
gnutls-2.8.5-14.el6_5.x86_64

Steps to Reproduce:
1. Configure SSL SHA2 certificate with apache/subversion 
2. Run svn list

Actual results:
Prompted for certificate-validation

Expected results:


Additional info:

Comment 1 Nikos Mavrogiannopoulos 2014-11-15 16:48:18 UTC

SHA2 is a large family of algorithms. Which algorithm does not work in that case? The site referenced in the report is not public so its certificate is not available. The debian report mentions that SHA1 and SHA2-256 works. Does SHA2-256 work in that case too?

Comment 4 Nikos Mavrogiannopoulos 2014-11-18 10:27:42 UTC

I attempted to validate the report in RHEL-6.6, but I couldn't. As far as I see SHA256 certificates are supported in that version. Please provide more information if that is really an issue in the gnutls component or I'll close it as not a bug.

# gnutls-cli --version
gnutls-cli (GnuTLS) 2.8.5

# gnutls-cli www.sha2sslchecker.com --x509cafile /etc/pki/tls/certs/ca-bundle.crt 
 - Got a certificate list of 4 certificates.
 - Certificate[0] info:
  - subject `OU=Domain Control Validated,OU=PositiveSSL,CN=www.sha2sslchecker.com', issuer `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2014-09-23 00:00:00 UTC', expires `2015-09-23 23:59:59 UTC', SHA-1 fingerprint `17930cb187632fb189b87e58b6b5792c6214650e'
 - Certificate[1] info:
  - subject `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA', issuer `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Certification Authority', RSA key 2048 bits, signed using RSA-SHA384, activated `2014-02-12 00:00:00 UTC', expires `2029-02-11 23:59:59 UTC', SHA-1 fingerprint `339cdd57cfd5b141169b615ff31428782d1da639'
 - Certificate[2] info:
  - subject `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Certification Authority', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 4096 bits, signed using RSA-SHA384, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0'
 - Certificate[3] info:
  - subject `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 2048 bits, signed using RSA-SHA, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `02faf3e291435468607857694df5e45b68851868'

- The hostname in the certificate matches 'www.sha2sslchecker.com'.
- Peer's certificate is trusted

Comment 10 Nikos Mavrogiannopoulos 2014-11-18 19:06:36 UTC

His issue is not SHA256, but the fact that the server is misconfigured. The certificate list sent by the server isn't ordered. TLS servers must send their certificates in an order that each certificate certifies the next [0]. GnuTLS in RHEL-7 automatically reorders since this proved to be a very common misconfiguration and that's the reason it works.

[0]. see http://tools.ietf.org/html/rfc5246#section-7.4.2 "
The sender's certificate MUST come first in the list.  Each following      certificate MUST directly certify the one preceding it."

The list of certificates on the server need to be reordered to 0, 3, 2, 1.

 - Certificate[0] info:
  - subject `C=US,2.5.4.17=#13053835373231,ST=Arizona,L=Tucson,STREET=1077 N Highland Ave,STREET=Computer Center,O=The University of Arizona,OU=UITS,CN=subversion.uits.arizona.edu', issuer `C=US,ST=MI,L=Ann Arbor,O=Internet2,OU=InCommon,CN=InCommon RSA Server CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2014-11-05 00:00:00 UTC', expires `2017-11-04 23:59:59 UTC', SHA-1 fingerprint `d52a4d1904d72fc17ecea0dd3e7d7588a90fd571'
 - Certificate[1] info:
  - subject `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 2048 bits, signed using RSA-SHA, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `02faf3e291435468607857694df5e45b68851868'
 - Certificate[2] info:
  - subject `C=US,ST=New Jersey,L=Jersey City,O=The USERTRUST Network,CN=USERTrust RSA Certification Authority', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 4096 bits, signed using RSA-SHA384, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `eab040689a0d805b5d6fd654fc168cff00b78be3'
 - Certificate[3] info:
  - subject `C=US,ST=MI,L=Ann Arbor,O=Internet2,OU=InCommon,CN=InCommon RSA Server CA', issuer `C=US,ST=New Jersey,L=Jersey City,O=The USERTRUST Network,CN=USERTrust RSA Certification Authority', RSA key 2048 bits, signed using RSA-SHA384, activated `2014-10-06 00:00:00 UTC', expires `2024-10-05 23:59:59 UTC', SHA-1 fingerprint `f5fb01dea6e59ca6dd057054f4a3ff72dde1d5c6'

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