Project

General

Profile

Bug #16179

Updated by John Mitsch over 8 years ago

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1320179  
  +++ This bug was initially created as a clone of Bug #1242310 +++ 

 +++ This bug was initially created as a clone of Bug #1128870 +++ 

 Description of problem: 

 Published repositories give 403 forbidden when attempting to navigate to the https address 


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

 How reproducible: 
 Choose organization, then Content > Content Views, choose Content> repositories click the repository and try to navigate to 'Published At' link to receive. 

 Forbidden 

 You don't have permission to access /pulp/repos/ACME_Corporation/Library/content/dist/rhel/server/6/6Server/x86_64/os on this server. 

 Actual results: 
 Can browse repos via HTTP but on HTTPS port it fails with below error 

 Forbidden 

 You don't have permission to access /pulp/repos/RedHat/ on this server. 

 Expected results: 
 Rpos should be browsable via https repo 

 Additional information:  

 Followed the steps provided in https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html-single/User_Guide/#Create_a_New_Organization_Debug_Certificate 

 Still the repos are not browsable via HTTPS port. Below are my findings  

  # cat /etc/httpd/conf.d/pulp_nodes.conf file 

 # -- HTTP Repositories --------- 

 Alias /pulp/nodes/http/repos /var/www/pulp/nodes/http/repos 

 <Directory /var/www/pulp/nodes/http/repos > 
   Options FollowSymLinks Indexes 
 </Directory> 

 # -- HTTPS Repositories --------- 

 Alias /pulp/nodes/https/repos /var/www/pulp/nodes/https/repos 

 <Directory /var/www/pulp/nodes/https/repos > 
   Options FollowSymLinks Indexes 
   SSLRequireSSL 
   SSLVerifyClient require 
   SSLVerifyDepth    5 
   SSLOptions +FakeBasicAuth 
   SSLRequire %{SSL_CLIENT_S_DN_O} eq "PULP" and %{SSL_CLIENT_S_DN_OU} eq "NODES"     ------> This line is causing the trouble as its expecting Org to be PULP and OU to be NODES in the CA cert which is why its failing 
 </Directory> 

 Also we can see some traceback/errors in the /var/log/httpd/foreman-ssl_error_ssl.log when accessing content on HTTPS port. 

 [root@dhcp233-55 ~]# tail -f -n0 /var/log/httpd/foreman-ssl_error_ssl.log 
 [Mon Jul 13 07:40:09.924854 2015] [:error] [pid 31432] [client 10.65.223.44:55319] mod_wsgi (pid=31432): Exception occurred processing WSGI script '/srv/pulp/repo_auth.wsgi'. 
 [Mon Jul 13 07:40:09.924963 2015] [:error] [pid 31432] [client 10.65.223.44:55319] Traceback (most recent call last): 
 [Mon Jul 13 07:40:09.925010 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/srv/pulp/repo_auth.wsgi", line 34, in allow_access 
 [Mon Jul 13 07:40:09.925175 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       authorized = _handle(environ) 
 [Mon Jul 13 07:40:09.925203 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/srv/pulp/repo_auth.wsgi", line 71, in _handle 
 [Mon Jul 13 07:40:09.925246 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       result = f(environ) 
 [Mon Jul 13 07:40:09.925274 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/usr/lib/python2.7/site-packages/pulp_rpm/repo_auth/oid_validation.py", line 46, in authenticate 
 [Mon Jul 13 07:40:09.925735 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       environ["wsgi.errors"].write) 
 [Mon Jul 13 07:40:09.925786 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/usr/lib/python2.7/site-packages/pulp_rpm/repo_auth/oid_validation.py", line 120, in is_valid 
 [Mon Jul 13 07:40:09.925837 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       is_valid = self._check_extensions(cert_pem, dest, log_func) 
 [Mon Jul 13 07:40:09.925863 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/usr/lib/python2.7/site-packages/pulp_rpm/repo_auth/oid_validation.py", line 166, in _check_extensions 
 [Mon Jul 13 07:40:09.925904 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       cert = certificate.create_from_pem(cert_pem) 
 [Mon Jul 13 07:40:09.925930 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/usr/lib64/python2.7/site-packages/rhsm/certificate.py", line 64, in create_from_pem 
 [Mon Jul 13 07:40:09.926441 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       return _CertFactory().create_from_pem(pem) 
 [Mon Jul 13 07:40:09.926529 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/usr/lib64/python2.7/site-packages/rhsm/certificate2.py", line 74, in create_from_pem 
 [Mon Jul 13 07:40:09.927029 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       return self._read_x509(_certificate.load(pem=pem), path, pem) 
 [Mon Jul 13 07:40:09.927160 2015] [:error] [pid 31432] [client 10.65.223.44:55319]     File "/usr/lib64/python2.7/site-packages/rhsm/certificate2.py", line 100, in _read_x509 
 [Mon Jul 13 07:40:09.927304 2015] [:error] [pid 31432] [client 10.65.223.44:55319]       raise CertificateException(str(e)) 
 [Mon Jul 13 07:40:09.927491 2015] [:error] [pid 31432] [client 10.65.223.44:55319] CertificateException: Invalid date Bad time value: Invalid month: Bad 
 [Mon Jul 13 07:40:09.927717 2015] [:error] [pid 31432] [client 10.65.223.44:55319] mod_wsgi (pid=31432): Client denied by server configuration: '/var/www/pub/yum/https/repos/RedHat'. 

 [root@dhcp233-55 ~]# date 
 Mon Jul 13 07:40:32 IST 2015 

 --- Additional comment from RHEL Product and Program Management on 2015-07-12 22:24:20 EDT --- 

 Since this issue was entered in Red Hat Bugzilla, the release flag has been 
 set to ? to ensure that it is properly evaluated for this release. 

 --- Additional comment from RHEL Product and Program Management on 2015-07-12 22:26:00 EDT --- 

 Since this issue was entered in Red Hat Bugzilla, the pm_ack has been 
 set to + automatically for the next planned release 

 --- Additional comment from Fred van Zwieten on 2015-09-07 08:15:40 EDT --- 

 Possibly related, but not a dup afaict: https://bugzilla.redhat.com/show_bug.cgi?id=1260560 

 --- Additional comment from DipenDevra on 2015-09-10 05:15:06 EDT --- 

 Hello, 

 I have a case(SFDC#01505222), in which Customer is asking for the further update/timeline/ of Bug. 

 Thanks and Regards, 
 Dipen Devra 

 --- Additional comment from Bryan Kearney on 2015-10-09 08:41:24 EDT --- 

 Using Tazims machines, I see: 

 [bkearney@fivehole code] $ curl -k --cert /home/bkearney/Downloads/Default\ Organization-key-cert.pem    https://dell-pe1955-01.rhts.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/content/dist/rhel/server/6/6.6/x86_64/os 
 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> 
 <html><head> 
 <title>403 Forbidden</title> 
 </head><body> 
 <h1>Forbidden</h1> 
 <p>You don't have permission to access /pulp/repos/Default_Organization/Library/content/dist/rhel/server/6/6.6/x86_64/os 
 on this server.</p> 
 </body></html> 


 And, if I try and look at the cert I see, 

 [bkearney@fivehole code] $ rct stat-cert /home/bkearney/Downloads/Default\ Organization-key-cert.pem  
 Unable to read certificate file '/home/bkearney/Downloads/Default Organization-key-cert.pem': Invalid date Bad time value: Invalid month: Bad 


 Attaching the cert 

 --- Additional comment from Bryan Kearney on 2015-10-09 08:42 EDT --- 



 --- Additional comment from Joseph Kachuck on 2015-11-09 14:34:06 EST --- 

 May I allow IBM access to this BZ? 

 Thank You 
 Joe Kachuck 

 --- Additional comment from Mike McCune on 2015-11-24 16:34:32 EST --- 

 BZ is now public. 

 --- Additional comment from Justin Sherrill on 2016-03-03 17:00:59 EST --- 

 After chatting with the candlepin team, this seems like it may be a bug in m2crypto.   

 I wrote a small python script https://gist.github.com/jlsherrill/ad4e9a7122c08e6a7436 to test a particular cert and the uber certs seem to fail.   

 Al's analysis indicates that certs with an expiration date after 2050 fail to validate in m2crypto. 

 --- Additional comment from Justin Sherrill on 2016-03-04 08:10:08 EST --- 

 This is also preventing capsule syncing from working in Satellite 6.2. 

 --- Additional comment from Alex Wood on 2016-03-07 14:29:12 EST --- 

 Filed upstream bug with M2Crypto at https://gitlab.com/m2crypto/m2crypto/issues/103 

 However, python-rhsm only uses M2Crypto to read version 1 entitlement certificates.    Version 3 entitlement certificates are read via a C extension.    The same problem exists in that extension as well (GeneralizedTimes being interpreted as UTCTimes).    See https://github.com/candlepin/python-rhsm/blob/d437f96f0aa3311f4b9b21a5fd128825ecc52f72/src/certificate.c#L447 

 The fastest fix is to path Candlepin to not issue certificates with an expiration date past 2050. 

 --- Additional comment from Bryan Kearney on 2016-03-07 16:06:15 EST --- 

 Upstream bug component is Capsule 

 --- Additional comment from Bryan Kearney on 2016-03-10 14:50:04 EST --- 

 Upstream bug assigned to jomitsch@redhat.com 

 --- Additional comment from Justin Sherrill on 2016-03-10 14:56:45 EST --- 

 Unlinked from upstream issue as the problem is being resolved in candlepin 

 --- Additional comment from Brad Buckingham on 2016-03-21 12:34:02 EDT --- 

 Moving all beta bugs without blocker+ to GA.

Back