Lets Encrypt Certificate #2 not trusted

Discussion in 'General' started by Dride, Oct 14, 2020.

  1. Dride

    Dride New Member

    Hi,
    i have a root server with multiple domains. Each of those domains have independend subdomains (added under ispconfig/subdomain). Everything verifies fine (ssllabs.com -> A+) - i thought.

    Some of my clients told me, that they had problems under Windows(10?) and some Versions of the Internet Explorer. There they were told that the site was not secure (typical certificate warning). If they then clicked on "load anyway", they would always end up on a subdomain. Interestingly, all customers ended up on the same subdomain (cloud.nordicalbums.com).

    So I checked the certificate chain again for all of my main domains (e.g. nordicalbums.com) with ssllabs.com and there is a second certificate (for cloud.nordicalbums.com) that is delivered together with every main domain which always points to the one subdomain but is invalid.

    Interestingly, this subdomain has been created by ispconfig under /sites-available/ before all other domains. Maybe this is related to it.

    Here you can see it as a screenshot or check it yourself on ssllabs.com

    Can you explain this? I am at the moment at a loss.
    Best regards
     

    Attached Files:

  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    For that cloud.nordicalbums.com, what does ISPConfig panel show for
    Don't add to Let's Encrypt Certificate: | |
     
  3. Dride

    Dride New Member

    Thanks for your reply!
    cloud.nordicalbums.com was added, as any other domain and subdomain under ispconfig->website and not subdomains or aliasdomains. Those subdomains where separate websites with their own services as nextcloud, mail, databases etc. pp. Sorry thats what i meant with "independend".
     

    Attached Files:

    Last edited: Oct 14, 2020
  4. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Are you using Apache or nginx? Do you have a custom vhost in the conf-custom folder?
     
  5. Dride

    Dride New Member

    Thanks for your reply @Th0m
     

    Attached Files:

  6. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Can you share that custom vhost.conf.master?
     
  7. Steini86

    Steini86 Active Member

    It is! Be aware of the "no SNI" label on the second certificate. That means that this certificate is sent to clients that do not support SNI (virtual hosts). When apache is configured with virtual hosts, these clients will get the first loaded virtual host (in your case cloud. ...). (That's also the website, that is shown when using your IP address to connect without specifying a hostname)

    You can try setting the option (I have not tested this, it's on my todo-list) "SSLStrictSNIVHostCheck on", then clients without SNI support should get an error message instead of a wrong website. See https://cwiki.apache.org/confluence/display/HTTPD/NameBasedSSLVHostsWithSNI for more details.

    Maybe your clients do not support TLS1.2+ ? Ask your users about their browser and exact version.
     
    Jesse Norell likes this.
  8. ahrasis

    ahrasis Well-Known Member

    Please ensure all websites use either ip address or asterisk and not the mixed of both.
     
  9. Dride

    Dride New Member

    @Steini86 Thanks for your hint!
    Indeed, they get an error message! Thanks. That could be a temp. solution for me. In reality, this is hardly a problem for us, because the customers with error messages are only a very small percentage. Nevertheless, it would be nice if something like this did not happen at all.

    For me, the question arises why the subdomain "cloud" does not have an SNI. When I have the subdomain checked by ssllabs, one and the same certificate suddenly has SNI. Strange or?

    @ahrasis yep. All Domains have the korrekt IPv4 and IPv6 in their settings.

    @Th0m Have a look at my attachment. Thanks for your help!
     

    Attached Files:

    Last edited: Oct 15, 2020
  10. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Don't forget these replies ;)
     
    Dride likes this.
  11. Dride

    Dride New Member

    @Th0m Sorry, i'm too slow. See my last post.
     
  12. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    I don't see anything weird in your vhost.

    So there is no domain that uses * for the IP address?
     
  13. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    SNI is a feature of the ssl connection, it is not something that is enabled on a per-vhost basis. cloud.nordicalbums.com is your default/first defined vhost, so when either a connection does not use SNI, or it requests a server name that does not have a matching a vhost, you will get the cloud.nordicalbums.com certificate served to you (you can verify that with `openssl s_client -connect 5.9.30.221:443 -noservername`). Run `apachectl -S` and it will show you your defined vhosts (including server names) and which is the default for each ip/port.
     
  14. Steini86

    Steini86 Active Member

    Just to illustrate the problem:
    A user wants to go to cloud.domain.com. The browser will do a DNS request on cloud.domain.com and get an IP address back. The browser will connect to that IP address (not the domain!) and request the webpage. A SNI capable browser will additionally send the information that it wants to connect to cloud.domain.com and Apache will serve the vhost that matches this domain. If that domain does not exist, it will serve the first configured vhost (this happens for example, when you have configured a wildcard-DNS and someone tries to connect to nonexistent.subdomain.domain.com).
    On the other hand, a non-SNI capable browser will only connect to the IP and request a webpage (this is from the last millennium where one webserver did only serve one webpage). Apache does not know which domain (vhost) and will serve the first configured.

    You have basically three options to avoid this problem with non-SNI capable clients (although they should slowly become extinct):
    1. Make your main site the default (problem with other domains will still exist)
    2. Use a (wildcard) certificate which is valid for all your (sub)domains. Then the client will always get a valid certificate (might still get the wrong website, though)
    3. Have a dedicated IP address for your main site that only hosts this site (basically not using SNI). While this is easy with IPv6 where you have practically unlimited IPs, an additional IPv4 address will cost you extra. And clients not capable of SNI will probably not support IPv6
    Quick solution might be 1, but that could be overwritten by ispconfig resyncs. Apache processes the contents of config sub-directories in alpha-numeric sort order. So renaming your main site in the sites-enabled folder to something like "000-.." such that it is the first in alpha-numeric ordering will make it the default page. I don't know if you can do that in a way that ISPC is not overwriting that change, though..
     
  15. Dride

    Dride New Member

    @Th0m I double checked the Domains. No Domain with an asteriks. Every domain use THE correct IPv4 and IPv6 Address.
     
  16. Dride

    Dride New Member

    @Jesse Norell @Steini86 Thanks for your explanations!

    You're right. 1. and 2. are no options. I will go with 3. as this seems to be the best option for this small customer group.

    Thanks a lot for your help!
    Greetings!
     
  17. ahrasis

    ahrasis Well-Known Member

    I have a wild guess about ipv6 that may cause your problem, so if I were you, I will test disabling ipv6 and see how it goes. I personally always have problems with ipv6 and still haven't found the right way to use it smoothly on my servers.
     
  18. Steini86

    Steini86 Active Member

    I would advise against turning off IPv6 in 2020. Depending on your region and customers you will cut them off. Here, there is only IPv6 for mobile users and they will all be excluded then.
     
  19. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

  20. ahrasis

    ahrasis Well-Known Member

    On the contrary actually, I do believe I said "test disabling ipv6" and to me it will allow you to determine if you have any problems with it.

    While running test by disabling ipv6, I don't think it will cut you from anyone at all, provided your ipv4 is already properly set and working.

    Anyway, as said, it is just a wild guess and you can simply ignore doing such a test.
     

Share This Page