tunloop
commented
3 months ago Additional information, since post was limited by characters
Jul 18 12:57:03 WebProxy squid[108450]: ERROR: failure while accepting a TLS connection on conn67 local=172.20.20.10:3142 remote=172.20.20.5:48320 FD 13 flags=1: 0x5a66a2522130*1
current master transaction: master89
Jul 18 12:57:03 WebProxy squid[108450]: {"log":"squid-access","time":"18/Jul/2024:12:57:03 -0700","responseTime":21,"srcIp":"172.20.20.5","srcPort":"48320","destIp":"-","destPort":"-","userIdent":"-","user":"-","method":"CONNECT","httpVer":"1.1","url":"apps.nextcloud.com:443","referrer":"-","userAgent":"-","status":"200","reqAction":"NONE_NONE","reqStatus":"HIER_NONE","contentType":"-","bytes":103,"bytesIn":103,"bytesOut":0}PCAP showing that nextcloud is closing the connection because it does not trust the CA cert.
Not an issue with Squid, curl on the nextcloud server using the system CA cert store functions just fine:
curl --cacert /etc/ssl/certs/ca-certificates.crt -vvv https://apps.nextcloud.com > /tmp/file
* Uses proxy env variable https_proxy == 'http://apt.example.com:3142'
Trying 172.20.20.10:3142...
* Connected to apt.example.com (172.20.20.10) port 3142 (#0)
* allocate connect buffer
* Establish HTTP proxy tunnel to apps.nextcloud.com:443
> CONNECT apps.nextcloud.com:443 HTTP/1.1
> Host: apps.nextcloud.com:443
> User-Agent: curl/7.88.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2918 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [520 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=apps.nextcloud.com
* start date: Jul 13 23:41:26 2024 GMT
* expire date: Jul 11 23:41:26 2034 GMT
* subjectAltName: host "apps.nextcloud.com" matched cert's "apps.nextcloud.com"
* issuer: C=US; ST=Washington; O=; CN=example.com; emailAddress=admin@example.com
* SSL certificate verify ok.
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: apps.nextcloud.com
> User-Agent: curl/7.88.1
> Accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [233 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [233 bytes data]
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
joshtrichards
⚠️ This issue respects the following points: ⚠️
Bug description
Nextcloud outbound HTTP communications through forward HTTP proxy specified in
config.phpdoes not utilize the system ca store (on Debian:/etc/ssl/certs/ca-certificates.crt) even when CA file is explicitly specified in both FPM and CLI php.ini configuration files. (cURL error 35 - unknown CA)Steps to reproduce
'proxy' => '172.20.20.10:3142',)openssl.cafile=/etc/ssl/certs/ca-certificates.crt)Expected behavior
Nextcloud, when using an HTTP proxy, should trust all CA certificates in system store.
Installation method
N/A
Nextcloud Server version
28
Operating system
Debian 12
PHP engine version
PHP 8.3
Web server
NGINX
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Unk/N/A
Are you using the Nextcloud Server Encryption module?
No
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs - Limited (Github 65K character limit)
Additional info
No response