[squid-users] yum update fails when using squid even though .redhat.com is whitelisted
Berger J Nicklas
nicklas.berger at scania.com
Thu Nov 21 09:16:17 UTC 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20191121/9c1123bd/attachment-0001.html>
More information about the squid-users
mailing list