1

I've created a developer cert with my companies CA for my development box. The CN is the FQDN of my development box mybox.example.com, but I've also added subjectAlternative names that include localhost so even when I'm using localhost the cert is trusted.

The relevant details are:

Subject: CN=mybox.example.com; O=cool org; OU=Acme
Issued by: CN=Acme CA 1; O=IT; OU=Acme
Subject Alternative Names:
DNS Name: localhost
DNS Name: mybox.example.com
 . . . others . . .

NOTE: The companies CA certs are loaded in my browser so all certs signed by this Certificate Authority are trusted in the browser.

When I'm on my development box (i.e, mybox.example.com) and open my local browser to https://localhost:8443/myapp, the browser shows the certificate as trusted (as I expected it would). I can also use my FQDN name of https://mybox.example.com:8443/myapp and the browser also shows the certificate as trusted.

In the above case, I'm actually running on an EC2 instance.

I'm first logged into an AWS Linux Desktop, and then I ssh to my EC2 instance and have X forwarding enabled (which allows me to open chrome on my EC2 instance and have it displayed on my AWS Desktop). The diagram looks like this:

AWS Desktop      => ssh (with X Forwarding) ==> EC2 Instance (mybox.example.com)
XWindows Server <-----------------------------> chromium-browser
                                                MyApp:8443

This all works perfectly as expected. The chromium-browser running on my EC2 instance uses URL https://localhost:8443/myapp to connect to MyApp:8443 via localhost and it all works and the browser says the certificate is trusted.

Next, however, the browser says the certificate is not trusted, and I don't know why. The diagram looks like this:

AWS Desktop         ==> ssh tunnel (on port 8443) ==> EC2 Instance (mybox.example.com)
chromium-browser https://localhost:8443/myapp <---->  myapp:8443

I have configured ssh tunnels and X Forwarding in my $HOME/.ssh/config file as follows:

Host mybox.example.com  dev
    HostName mybox.example.com
    ForwardX11 yes
    ForwardX11Trusted yes
    LocalForward 8080 localhost:8080
    LocalForward 8443 localhost:8443

The above configuration allows me to open X windows apps on my EC2 instance and have them displayed on my AWS Linux Desktop. And also sets up ssh tunnels for ports 8080 and 8443.

So when I open my browser on my AWS Desktop host, I can hit the apps that are running on my EC2 instance. When I do this, the chromium browser running on my AWS Desktop complains that the certificate is not trusted (even though it is the same certificate as served in the 1st example which is trusted).

My question is why is the certificate not trusted when going through the ssh tunnel?

Searching for this answer is difficult because of the complexity of the setup.

Answers to comments

What exactly does the browser say?

@Steffen Ullrich commented:

"the browser says the certificate is not trusted" - what exactly does the browser say. Please provide the exact error message you get, including the advanced details offered.

It says Not Secure next to the URL, and the string https of the URL is in red and has a red strikethrough on it.

If I click to view the certificate, there is nothing highlighted in the certificate to indicate what the browser doesn't like (but I'm not sure what if anything I would see). I can't share the exact cert with you for company privacy reasons.

Here is a screenshot

The page shows this warning page (I clicked on Show advanced, as requested in the comment).

Check both browsers CA store

Note that the browser uses its own root CA store, so you need to check what root CA are installed in the specific browser instance you are using.

This comment resulted in me finding the answer. When I checked the browser's on my AWS Desktop, I found that the CA store did have the internal CA certs needed, but the Anchor (top level) Root CA was not trusted. I didn't track down why but instead copied the CA cert from the working browser (EC2) to the AWS Desktop browser and the problem went away.

The trust change was:

CN=mybox.example.com; O=cool org; OU=Acme
CN=Acme CA 1; O=IT; OU=Acme   <<< Trusted on EC2 not trusted on AWS Desktop

Please feel free to write this up as an answer and I'll select it.

2
  • "the browser says the certificate is not trusted" - what exactly does the browser say. Please provide the exact error message you get, including the advanced details offered. Also, from my understanding it fails to work once you run the browser on another system (AWS desktop) - which suggests that the necessary CA is not trusted in the browser running on this system. Note that the browser uses its own root CA store, so you need to check what root CA are installed in the specific browser instance you are using. Mar 11, 2023 at 4:36
  • Browsers may explicitly prevent "localhost" from being valid. Have you considered a dynamic SOCKS proxy instead? ssh -D1080 remotehost then configure your browser to use that SOCKS proxy (consider FoxyProxy (for Firefox or for Chrome, which will let you select different proxies based on the target site). Then you just go there in your browser.
    – Adam Katz
    Mar 12, 2023 at 21:10

2 Answers 2

1

The problem is that your AWS desktop (either the OS as a whole or the browser you're using on it specifically) doesn't trust the certificate. Specifically, either it doesn't consider the internal CA to be a trusted CA (possibly because the CA cert isn't installed at all, or is installed incorrectly), or it considers one of the certs (CA or site) to be invalid for some reason.

The reason you don't see this problem in the other cases is because in all those cases, the browser is running on the EC2 instance, so it uses the certificate store there. In the last case, the browser is running on the AWS desktop - a completely different machine, which shares zero certificate store with the EC2 instance - and so even though it's connecting through SSH, the browser on the AWS desktop is using its own certificate store, which is NOT the one on the EC2 instance. The site certificate is being relayed through the SSH tunnel from the EC2 host to the AWS desktop, and the browser on the AWS desktop doesn't recognize it as valid.

The SSH tunnel is actually irrelevant here. SSH never (unless you're doing something very odd) has any impact on what certs a browser considers trusted. You'd get exactly the same error if you pointed the browser on the AWS desktop at https://mybox.example.com/ (or any other name for the EC2 instance) without using SSH (assuming the server was exposed at all). Also, it would work fine if instead of SSH you used RDP or VNC to connect to the EC2 instance and ran the browser there, since that browser does trust the CA.

It really does just come down to "does this specific browser installation trust the cert?" The one on your EC2 instance does. The one on your AWS desktop does not. It's that simple. The questions of how you view the browser, or how the browser connects to the server, is all distraction.

To correct the issue, make sure that the internal CA certificate is installed, and trusted, as a CA certificate for the AWS desktop (and, if relevant, its browser; e.g. Firefox does not use the system certificate store).

1

If a server certificate works in one instance (client to server) but not in another, then the CA Trust Chain is the likely cause.

Another cause is that a certificate has been revoked; one client still trusts the certificate because it doesn't check the revocation list, the other fails to trust it because it does check the revocation list. This is less likely to be the reason.

In general, a certificate can be untrusted for several reasons. I'll group the reasons into Certificate Data, CA Trust Chain and Interoperability.

Certificate Data

  1. The certificate data isn't suitable for some reason.
    1. The FQDN listed in the cert doesn't match FQDN being used for the connection.
    2. The Certificate Usage does not include TLS WWW Server Authentication (this is meant to be an example, not the only reason).
    3. The Cert Signature Algorithm isn't supported by the client. (unlikely)

Implementations of the client side validation can vary between languages; java, python, C/C++, C# and so there above list is not intended to be complete but give a couple examples that illustrate why a cert's data might not be acceptable.

The above has nothing to do with the CA trust chain. The client just doesn't like something in the server's cert.

CA Trust Chain

The next category of reasons for a cert being untrusted has to do with the Certificate Authority's used in the certificate.

  1. The Certificate Authority Trust chain is not present or incomplete.

    1. The Server's Issuer does not appear in the client CA TrustStore, or it is but it isn't trusted.
    2. The Server's issuer is an intermediate CA and it is trusted, but it's issuer is either not present or not trusted. This repeats to the top of the Trust Chain to the Trust Anchor (aka Root CA).
  2. The certificate (or any certificate in the chain) has been revoked. Defaults and enabling disabling can affect validation, see X.509 Certificate Revocation Checking (for Java)

Interoperability

  1. SSL/TLS version protocol incompatibility. Because security issues have been found with older versions of SSL & TLS See End of SSL 3.0, servers should be configured to not allow connections from clients that want to use insecure versions of the protocol. When this happens the server refuses to allow a connection.

  2. The Cipher Suites configured on the server are not supported by the client. This is similar to the TLS version issue above, but it is with the Cipher's being used. [See Cloudflare What happens in a TLS handshake] . That says:

**The 'client hello' message ... says which TLS version the client supports, the cipher suites supported.

If the server won't support any cipher suite that the client wants to use, then a secure SSL connection can't be achieved.

I saw this when a unsecured client tried (very old Chromium) talking to a secured server and the server refused to accept the connection, but the server would accept a connection using the curl command.

  1. Bug in the SSL Handshake (client to server) protocol. This is unlikely but possible.

This doesn't show up as a certificate error but instead as a SSL protocol error.

Summary

With the above said, in this case you can rule out issues with the format of the cert because the client is the same in both cases (Chromium) and trusts the data in the cert.

The next possible issue is the CA Trust Chain.

The last is the revocation list (has a certificate in the trust chain been revoked).

The issue of using an SSH tunnel is irrelevant. As @CBHacking said:

The questions of how you view the browser, or how the browser connects to the server, is all distraction.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .