Arch Linux

a11eyezonme

Member

Registered: Today

Posts: 7

ssh forwarding

Hey guys! I’m pretty new to Arch. I’ve installed the base system, and now I’m trying to proxy my browser through SSH using ssh -D 2222 root@address -f -N.

However, Firefox doesn’t trust certificates in this setup. I’ve already installed ca-certificates, ca-certificates-utils, and ca-certificates-mozilla, but nothing changed.

My other laptop running Debian doesn’t have this issue via same connection.

mithrial

Member

Registered: 2017-03-05

Posts: 148

Re: ssh forwarding

Which certificate and which page are you trying to access? Can't you access port 2222 without https?

a11eyezonme

Member

Registered: Today

Posts: 7

Re: ssh forwarding

Port is accesible, any site dosen't available

mithrial

Member

Registered: 2017-03-05

Posts: 148

Re: ssh forwarding

I'm lacking context. What are you trying to achieve with this port forwarding?

a11eyezonme

Member

Registered: Today

Posts: 7

Re: ssh forwarding

I am trying to forward all my traffic(explicitly in browser) through a VPS. As I said, I use it on Debian without any trouble. The issue is not the connection itself, as I understand it, the problem is with the certificates

cryptearth

Member

Registered: 2024-02-03

Posts: 2,026

Re: ssh forwarding

i guess OP tries to abuse ssh as socks proxy

a11eyezonme

Member

Registered: Today

Posts: 7

Re: ssh forwarding

i guess OP tries to abuse ssh as socks proxy

Yes, it clearly says so in the man page. Without abuse word btw

5hridhyan

Member

From: Asia

Registered: 2025-12-25

Posts: 515

Re: ssh forwarding

ssh -D just gives you a SOCKS proxy, it does not touch TLS in any way...
firefox still validates certificates directly with the destination, same as without ssh
so are you using SOCKS v5 in firefox?, did you enable "proxy DNS when using SOCKS v5"?, is your system time correct??, what exact error does firefox show (SEC_ERROR_* ?)
also try: does it work without proxy? does it work with curl using the same socks proxy?

Edit:
typo

Last edited by 5hridhyan (Today 18:38:44)

---

---

-thc

Member

Registered: 2017-03-15

Posts: 1,117

Re: ssh forwarding

Just tried it (out of academic interest) and it works without certificate errors.

a11eyezonme

Member

Registered: Today

Posts: 7

Re: ssh forwarding

ssh -D just gives you a SOCKS proxy, it does not touch TLS in any way...
firefox still validates certificates directly with the destination, same as without ssh
so are you using SOCKS v5 in firefox?, did you enable "proxy DNS when using SOCKS v5"?, is your system time correct??, what exact error does firefox show (SEC_ERROR_* ?)
also try: does it work without proxy? does it work with curl using the same socks proxy?

sock v5 enabled, DNS when using SOCKS v5 enabled, system time correct

Firefox error:

Secure Connection Failed

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
What can you do about it?

The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.

curl same issue

curl --socks5 localhost:2222 https://example.com -v
* Host localhost:2222 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:2222...
* Host example.com:443 was resolved.
* IPv6: 2606:4700::6812:1b78, 2606:4700::6812:1a78
* IPv4: 104.18.27.120, 104.18.26.120
* Opened SOCKS connection from ::1 port 54914 to example.com port 443 (via ::1 port 2222)
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=example.com
*   start date: Apr  2 21:18:57 2026 GMT
*   expire date: Jul  1 21:24:46 2026 GMT
*   issuer: C=US; O="CLOUDFLARE, INC."; CN=Cloudflare TLS Issuing ECC CA 1
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "example.com" matches cert's "example.com"
* OpenSSL verify result: 14
* SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
* closing connection #0
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.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 webpage mentioned above.

5hridhyan

Member

From: Asia

Registered: 2025-12-25

Posts: 515

Re: ssh forwarding

good, curl reproducing it confirms this is not a firefox-specific issue
does this also fail *without* the proxy?
because ssh -D does not affect TLS at all, so if it fails without the proxy as well, the issue is entirely local (trust store / crypto config)
also, you're negotiating X25519MLKEM768, which is a post-quantum hybrid key exchange, I guess Debian likely isn't using that yet..
try forcing a more standard handshake like

curl --tls-max 1.2 https://example.com -v

and also check your CA bundle

 ls -lh /etc/ssl/certs/ca-certificates.crt

---

---

a11eyezonme

Member

Registered: Today

Posts: 7

Re: ssh forwarding

good, curl reproducing it confirms this is not a firefox-specific issue
does this also fail *without* the proxy?
because ssh -D does not affect TLS at all, so if it fails without the proxy as well, the issue is entirely local (trust store / crypto config)
also, you're negotiating X25519MLKEM768, which is a post-quantum hybrid key exchange, I guess Debian likely isn't using that yet..
try forcing a more standard handshake like

curl --tls-max 1.2 https://example.com -v

and also check your CA bundle

 ls -lh /etc/ssl/certs/ca-certificates.crt

curl --tls-max 1.2 https://example.com -v
* Host example.com:443 was resolved.
* IPv6: 2606:4700::6812:1a78, 2606:4700::6812:1b78
* IPv4: 104.18.27.120, 104.18.26.120
*   Trying [2606:4700::6812:1a78]:443...
* Immediate connect fail for 2606:4700::6812:1a78: Network is unreachable
*   Trying 104.18.27.120:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
* TLSv1.2 (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-ECDSA-CHACHA20-POLY1305 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=example.com
*   start date: Apr  2 21:18:57 2026 GMT
*   expire date: Jul  1 21:24:46 2026 GMT
*   issuer: C=US; O="CLOUDFLARE, INC."; CN=Cloudflare TLS Issuing ECC CA 1
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "example.com" matches cert's "example.com"
* OpenSSL verify result: 14
* SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
* closing connection #0
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.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 webpage mentioned above.

~                                                                                                                                                                           
>  ls -lh /etc/ssl/certs/ca-certificates.crt
lrwxrwxrwx 1 root root 49 Jun 18  2024 /etc/ssl/certs/ca-certificates.crt -> ../../ca-certificates/extracted/tls-ca-bundle.pem

a11eyezonme

Member

Registered: Today

Posts: 7

Re: ssh forwarding

At the same time if i curl github, everything is ok

Server certificate:
*   subject: CN=github.com
*   start date: Mar  6 00:00:00 2026 GMT
*   expire date: Jun  3 23:59:59 2026 GMT
*   issuer: C=GB; O=Sectigo Limited; CN=Sectigo Public Server Authentication CA DV E36
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   subjectAltName: "github.com" matches cert's "github.com"
* OpenSSL verify result: 0
* SSL certificate verified via OpenSSL.
* Established connection to github.com (140.82.121.4 port 443) from *edited* port 46722

Last edited by a11eyezonme (Today 18:13:57)