Issue with SSL Certificate coming from a different customer

Expected behavior

For the CNAME DNS record setup to work properly.

Actual behavior

When visiting the site using Chrome, I get a “its security certificate is from This may be caused by a misconfiguration or an attacker intercepting your connection.”

In Firefox: “The certificate is only valid for”


Searching google lead me to a different topic in here (Production custom admin URL displays invalid SSL) – it appears that is a different Forest Customer, which makes this issue PARTICULARLY CONCERNING as it has revealed to me an internal forest customer URL / user that has nothing to do with me.

That thread seems to conclude it was a CloudFlare issue, but this seems unlikely to me that CloudFlare would mix up forest customers specifically, maybe I’m wrong though.

Hi @nachopescado,

This is indeed an issue related to Cloudflare, as stated on the thread you referenced (Production custom admin URL displays invalid SSL - #12 by james-janetech).

You must contact the cloudflare support in order to fix this issue. We also find this concerning, but sadly there is nothing much we can do on our end for this problem.

Let us know once this is fixed, and I hope it helps :pray:

Wild! I will reach out to them, would love to know why this happens!

1 Like

@jeffladiray I contacted CloudFlare, and I think it’s important to note I actually have the proxy disabled and am getting the error. They have replied with the following:

Hi there,

Thanks for contacting Cloudflare technical support. My name is Carol and I will be looking into this ticket for you. Sorry for the issues you are currently experiencing.

Currently the subdomain is not proxied by Cloudflare.

$dig +short

It is being served by the origin Let’s Encrypt certificate which does not include this hostname:

checkcert openssl s_client -connect -servername < /dev/null 2>/dev/null | openssl x509 -noout -text |grep ‘DNS:|Issuer:|Subject:’;
Issuer: C = US, O = Let’s Encrypt, CN = R3
Subject: CN =
$ curl -svo /dev/null

  • Trying…
  • Connected to ( port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: none
    } [5 bytes data]
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
    } [512 bytes data]
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
    { [102 bytes data]
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
    { [2471 bytes data]
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    { [333 bytes data]
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
    { [4 bytes data]
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    } [70 bytes data]
  • TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    } [1 bytes data]
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
    } [16 bytes data]
  • TLSv1.2 (IN), TLS handshake, Finished (20):
    { [16 bytes data]
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server accepted to use http/1.1
  • Server certificate:
  • subject:
  • start date: Apr 8 23:25:15 2021 GMT
  • expire date: Jul 7 23:25:15 2021 GMT
  • subjectAltName does not match
  • SSL: no alternative certificate subject name matches target host name ‘
  • Closing connection 0
    } [5 bytes data]
  • TLSv1.2 (OUT), TLS alert, close notify (256):
    } [2 bytes data]

That is why you get the SSL mismatch error.

Hey :wave:

On my end, running the same command with +trace
dig +trace

We, at ForestAdmin, do not own any certificates (Either for or and the only configuration we do is to allow these kind of custom domain to do request on We also do not handle anything related to your DNS configuration.

In your case, the connection is not secured because clients are being served a certificate signed for another domain. Which means that the provider serving the certificate is encountering an issue looking very similar to the thread you mentioned.

I asked the team if we have more informations on our end, and I’ll let you know if that’s the case.

1 Like

Thanks Jeff!

I will ping them again… what a crazy issue!

1 Like

If I run this command:

openssl s_client -connect -servername

I get back a cert for This SSL command should not do anything but connect to forestadmin. as -servername simply sets TLS SNI (Server Name Indication) extension in the ClientHello message, and should not go through cloudflare. (I think).

I will ping them again… what a crazy issue!

I totally agree with this. We spent a lot of time on the previous issue and the fact that you are getting a similar issue with a similar domain name (And that your domain is proxified by cloudflare) seems to indicate that the issue is similar. Also, and as previously stated, since we do not handle anything related to the DNS/Certificate related to your domain, there is not much we can do.

(I think too) openssl s_client -connect -servername must still rely on a dns resolution, but my DNS/networking knowledge stops there :frowning:

Jeff, appreciate the help.

Unfortunately I’m pretty convinced this is not CloudFlare,since the openSSL command does not rely on DNS, the servername variable there is similar to a HOST request in HTTP.

I’m going to suggest this is actually a heroku issue. When I configure the servername “” in the forest admin custom domain panel, that I am assuming is calling a Heroku Domain API call to configure that as a valid CNAME domain? This might be where the issue lies.

@jeffladiray I have 100% confirmed this is not CloudFlare. On a NameCheap DNS server, I configured, and lo and behold it returns an SSL cert/doimain for yet another Forest Admin customer (

This is either misconfiguration through Heroku or something else on your end, I have eliminated CloudFlare entirely.

INTERESTINGLY that didn’t last long.


It’s not CloudFlare, I think it’s Heroku. Regardless, the solution is the following:

openssl s_client -connect -servername <your_custom_domain>

Returns a mismatched subject=CN to your custom domain

solve by:

CHANGE the domain in forest admin panel to something else
CHANGE it back

now it works. :slight_smile:

1 Like


Sorry for the cloudflare misdirection then, and really happy to find out that you found a solution for your issue. Thanks for the detailed answer :raised_hands:

1 Like

No worries! That said I do think your team should elevate that to your heroku support >_<