yum update fails when using squid even though .redhat.com is whitelisted

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

yum update fails when using squid even though .redhat.com is whitelisted

Berger J Nicklas
We are using squid for both http and https whitelisting for egress. Most of the whitelisting works fine but some specific once do not work.
We have tried this on this versions of squid 3.5(amazon linux 2), 4.1(centos7) and 4.4(centos8).
For instance when running yum update for redhat linux in aws from a server using squid for egress it fails:

ec2-user]# yum update -v
Failed to set locale, defaulting to C
Loaded plugins: AmazonID, builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, uploadprofile
DNF version: 4.0.9
cachedir: /var/cache/dnf
repo: downloading from remote: rhui-client-config-server-8
error: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [SSL certificate problem: self signed certificate in certificate chain] (https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os).
Red Hat Update Infrastructure 3 Client Configuration Server 8                                                                                                                0.0  B/s |   0  B     00:01    
Cannot download 'https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os': Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [SSL certificate problem: self signed certificate in certificate chain].
Error: Failed to synchronize cache for repo 'rhui-client-config-server-8'

If I run curl against this URL:

ec2-user]# curl -v https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os
*   Trying 13.53.105.186...
* TCP_NODELAY set
* Connected to rhui3.eu-north-1.aws.ce.redhat.com (13.53.105.186) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Curl against https://www.redhat.com works fine.

ec2-user]# curl -v https://www.redhat.com
* Rebuilt URL to: https://www.redhat.com/
*   Trying 23.52.28.149...
* TCP_NODELAY set
* Connected to www.redhat.com (23.52.28.149) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=2945436; C=US; ST=North Carolina; L=Raleigh; O=Red Hat, Inc.; OU=IT; CN=www.redhat.com
*  start date: Mar 21 00:00:00 2018 GMT
*  expire date: Mar 20 12:00:00 2020 GMT
*  subjectAltName: host "www.redhat.com" matched cert's "www.redhat.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x56153e589630)
> GET / HTTP/2
> Host: www.redhat.com
> User-Agent: curl/7.61.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 301
< server: AkamaiGHost
< content-length: 0
< location: https://www.redhat.com/en
< date: Thu, 21 Nov 2019 08:47:55 GMT
<
* Connection #0 to host www.redhat.com left intact

My squid.conf looks like this:

visible_hostname localhost

# Handling HTTP requests
http_port 3128
http_port 3129 intercept

acl allowed_http_sites dstdomain .microsoft.com
acl allowed_http_sites dstdomain .google.com
acl allowed_http_sites dstdomain .redhat.com


http_access allow allowed_http_sites

# Handling HTTPS requests
acl SSL_port port 443
http_access allow SSL_port

acl allowed_https_sites ssl::server_name .microsoft.com
acl allowed_https_sites ssl::server_name .google.com
acl allowed_https_sites ssl::server_name .redhat.com

https_port 3130 intercept ssl-bump connection-auth=off generate-host-certificates=on dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ssl/squid.pem key=/etc/squid/ssl/squid.key

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1 all
ssl_bump peek step2 allowed_https_sites
ssl_bump splice step3 allowed_https_sites
ssl_bump terminate

http_access deny all


I assume this is related to that there is no certificate for this subdomain or similar? Is there a way to ignore this for ".redhat.com" or get yum update to work anyway?

// Nick









_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: yum update fails when using squid even though .redhat.com is whitelisted

Giles Coochey


On 21/11/2019 09:16, Berger J Nicklas wrote:
We are using squid for both http and https whitelisting for egress. Most of the whitelisting works fine but some specific once do not work.
We have tried this on this versions of squid 3.5(amazon linux 2), 4.1(centos7) and 4.4(centos8).
For instance when running yum update for redhat linux in aws from a server using squid for egress it fails:

ec2-user]# yum update -v
Failed to set locale, defaulting to C
Loaded plugins: AmazonID, builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, uploadprofile
DNF version: 4.0.9
cachedir: /var/cache/dnf
repo: downloading from remote: rhui-client-config-server-8
error: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [SSL certificate problem: self signed certificate in certificate chain] (https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os).
Red Hat Update Infrastructure 3 Client Configuration Server 8                                                                                                                0.0  B/s |   0  B     00:01    
Cannot download 'https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os': Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [SSL certificate problem: self signed certificate in certificate chain].
Error: Failed to synchronize cache for repo 'rhui-client-config-server-8'

The problem has nothing to do with Squid, https://rhui3.eu-north-1.aws.ce.redhat.com is indeed using a self-signed certificate.


You could add that cert to CA trust in your system, once you have verified the authenticity.


-- 
Giles Coochey

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: yum update fails when using squid even though .redhat.com is whitelisted

Kassir Bariq
In reply to this post by Berger J Nicklas

Hi,

 

You can add this line in your squid.conf

                    sslproxy_cert_error allow allowed_https_sites

this should fix your issue to bypass sites without a valid certificate.

 

Regards

Bariq

 

From: squid-users <[hidden email]> On Behalf Of Berger J Nicklas
Sent: den 21 november 2019 10:16
To: [hidden email]
Subject: [squid-users] yum update fails when using squid even though .redhat.com is whitelisted

 

We are using squid for both http and https whitelisting for egress. Most of the whitelisting works fine but some specific once do not work.

We have tried this on this versions of squid 3.5(amazon linux 2), 4.1(centos7) and 4.4(centos8).

For instance when running yum update for redhat linux in aws from a server using squid for egress it fails:

 

ec2-user]# yum update -v

Failed to set locale, defaulting to C

Loaded plugins: AmazonID, builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, uploadprofile

DNF version: 4.0.9

cachedir: /var/cache/dnf

repo: downloading from remote: rhui-client-config-server-8

error: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [SSL certificate problem: self signed certificate in certificate chain] (https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os).

Red Hat Update Infrastructure 3 Client Configuration Server 8                                                                                                                0.0  B/s |   0  B     00:01    

Cannot download 'https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os': Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [SSL certificate problem: self signed certificate in certificate chain].

Error: Failed to synchronize cache for repo 'rhui-client-config-server-8'

 

If I run curl against this URL:

 

ec2-user]# curl -v https://rhui3.eu-north-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os

*   Trying 13.53.105.186...

* TCP_NODELAY set

* Connected to rhui3.eu-north-1.aws.ce.redhat.com (13.53.105.186) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

* TLSv1.3 (OUT), TLS handshake, Client hello (1):

* TLSv1.3 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (OUT), TLS alert, unknown CA (560):

* SSL certificate problem: self signed certificate in certificate chain

* Closing connection 0

curl: (60) SSL certificate problem: self signed certificate in certificate chain

 

curl failed to verify the legitimacy of the server and therefore could not

establish a secure connection to it. To learn more about this situation and

how to fix it, please visit the web page mentioned above.

 

Curl against https://www.redhat.com works fine.

 

ec2-user]# curl -v https://www.redhat.com

* Rebuilt URL to: https://www.redhat.com/

*   Trying 23.52.28.149...

* TCP_NODELAY set

* Connected to www.redhat.com (23.52.28.149) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

* TLSv1.3 (OUT), TLS handshake, Client hello (1):

* TLSv1.3 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

* ALPN, server accepted to use h2

* Server certificate:

*  subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=2945436; C=US; ST=North Carolina; L=Raleigh; O=Red Hat, Inc.; OU=IT; CN=www.redhat.com

*  start date: Mar 21 00:00:00 2018 GMT

*  expire date: Mar 20 12:00:00 2020 GMT

*  subjectAltName: host "www.redhat.com" matched cert's "www.redhat.com"

*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA

*  SSL certificate verify ok.

* Using HTTP2, server supports multi-use

* Connection state changed (HTTP/2 confirmed)

* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0

* Using Stream ID: 1 (easy handle 0x56153e589630)

> GET / HTTP/2

> User-Agent: curl/7.61.1

> Accept: */*

>

* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!

< HTTP/2 301

< server: AkamaiGHost

< content-length: 0

< date: Thu, 21 Nov 2019 08:47:55 GMT

<

* Connection #0 to host www.redhat.com left intact

 

My squid.conf looks like this:

 

visible_hostname localhost

 

# Handling HTTP requests

http_port 3128

http_port 3129 intercept

 

acl allowed_http_sites dstdomain .microsoft.com

acl allowed_http_sites dstdomain .google.com

acl allowed_http_sites dstdomain .redhat.com

 

 

http_access allow allowed_http_sites

 

# Handling HTTPS requests

acl SSL_port port 443

http_access allow SSL_port

 

acl allowed_https_sites ssl::server_name .microsoft.com

acl allowed_https_sites ssl::server_name .google.com

acl allowed_https_sites ssl::server_name .redhat.com

 

https_port 3130 intercept ssl-bump connection-auth=off generate-host-certificates=on dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ssl/squid.pem key=/etc/squid/ssl/squid.key

 

acl step1 at_step SslBump1

acl step2 at_step SslBump2

acl step3 at_step SslBump3

 

ssl_bump peek step1 all

ssl_bump peek step2 allowed_https_sites

ssl_bump splice step3 allowed_https_sites

ssl_bump terminate

 

http_access deny all

 

 

I assume this is related to that there is no certificate for this subdomain or similar? Is there a way to ignore this for ".redhat.com" or get yum update to work anyway?

 

// Nick

 

 

 

 

 

 

 

 


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: yum update fails when using squid even though .redhat.com is whitelisted

Giles Coochey


On 21/11/2019 12:51, Kassir Bariq wrote:

Hi,

 

You can add this line in your squid.conf

                    sslproxy_cert_error allow allowed_https_sites

this should fix your issue to bypass sites without a valid certificate.

 


I probably wouldn't do this blindly, either use a different acl such as known_broken_cert_sites and add sites that you have trouble with to that ACL.

I believe Palo Alto and Bluecoats have a feature mechanism to provide the client with an appropriately broken cert , e.g. if the cert is expired, but has a trusted chain then it uses an expired cert with a trusted chain to the client, and if a cert is self signed, then it sends a self-signed cert to the client.

I don't know whether Squid also has that mechanism, but would probably be preferred.

-- 
Giles Coochey

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: yum update fails when using squid even though .redhat.com is whitelisted

Alex Rousskov
On 11/21/19 11:29 AM, Giles Coochey wrote:

> I believe Palo Alto and Bluecoats have a feature mechanism to provide
> the client with an appropriately broken cert , e.g. if the cert is
> expired, but has a trusted chain then it uses an expired cert with a
> trusted chain to the client, and if a cert is self signed, then it sends
> a self-signed cert to the client.

> I don't know whether Squid also has that mechanism

Yes, Squid also tries to mimic various aspects of origin server
certificate brokenness. Unfortunately, I do not think there is a wiki
table that fully documents which problems are mimicked by default, and I
do not remember all of the specifics. It would be great if somebody
would build such a table (e.g., by observing what Squid does with broken
certificates provided by various TLS testing web sites/services).

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users