Get the most out of your Centmin Mod LEMP stack
Become a Member

SSL DNS Letsencrypt Cloudflare Can anybody me clear the Cloudflare SSL mess I made please!

Discussion in 'Domains, DNS, Email & SSL Certificates' started by FluxTux, May 27, 2020.

  1. FluxTux

    FluxTux New Member

    21
    5
    3
    Sep 22, 2019
    Ratings:
    +9
    Local Time:
    4:40 PM
    However, even when changing the IP address back to the old server things were still messed up - now just with errors on connection timeouts with no end...

    I have no clue about certificates or how I borged this up... best guess: I shouldn't have installed the site with Letsencrypt SSL via acme tool on CMM while the domain dns was still pointing towards old server?

    maybe worth mentioning: Did not look like the CF Origin Certs I activated via the CF backend matched the one I generated at the Cloudflare backend... and come to thing of it creating that Origin Cert at CF might have been a mistake. Or the fact that I revoked it after a while presuming that I might be the cause of my misery.

    Generally I might have done the Origin Cert setup steps in the wrong order I guess?!?... can't even remember what order at this point, but as said think I may have done the Origin pull setup before i changed the A records to match the new CMM server... its all bit of a blur tbh.

    In a final desperate attempt to try and clear up the mess I made I then reverted the DNS A records back to the CMM server and cleared all record of the domain / website. I proceeded like this:

    1. UNINSTALLED WORDPRESS
    /root/tools/wp_uninstall_mydomain.com.sh

    2. DROPPED WP MySQL DATABASE:
    mysqladmin drop DBname

    3. REMOVED VHOST + CERTS:
    pure-pw userdel FTPusername
    rm -rf /usr/local/nginx/conf/conf.d/clientdomain.com.conf
    rm -rf /usr/local/nginx/conf/conf.d/clientdomain.com.ssl.conf
    rm -rf /usr/local/nginx/conf/ssl/clientdomain.com/clientdomain.com.crt
    rm -rf /usr/local/nginx/conf/ssl/clientdomain.com/clientdomain.com.key
    rm -rf /usr/local/nginx/conf/ssl/clientdomain.com/clientdomain.com.csr
    rm -rf /home/nginx/domains/clientdomain.com
    rm -rf /root/.acme.sh/clientdomain.com
    service nginx restart


    (looks like the first uninstall script made last steps obsolete but did them all just to make sure...)

    Then I reinstalled domain + WP + SSL from scratch following same procedure as first time - via CMM option 22. As far as Letsencrypt goes I once again went with the option "issue live cert with HTTPS default (trusted)"

    Installation finished with no errors afaict.

    But the SSL seems to somehow be a mess still - and when I try to visit the site I just get the same: ERR_TIMED_OUT

    I worry that I've somehow managed to mess the domains certificate up completely during my tweaking :banghead:

    I honestly have no clue as to where to go from here. The connection timeout error persist... I don't have the guts to tweak Cloudflare further at this point...

    Have no clue as to how to proceed... is the error due to a delay while DNS propagates? I have waited a couple of hours now and when I try to enter the site I still only get "connection is not safe" and after a short while connection times out.

    Am clueless and feel bad on part of my long term client whom I've let down figurering I had an understanding + setup that I don't (n):unsure: ... clearly I need to form a better understanding to avoid this in the future, but simply did not anticipate this...

    Anyway, need to get some rest now as I'm stressed and worn out - but I'll be back to this thread ASAP in hope of a little help from a few good samaritans... ??

    So... well.... yeah... would be extremely grateful if @eva2000 and/or anyone with a better grasp of this stuff would help me figure this one out... :dead:

    Kind regards with fingers crossed
    Mads

    P.s. have just changed the CF cert to full (had it on flexible on old server). I'm letting the Origin server setup be and just want focus on how to my friends site back online...
     
    Last edited: May 27, 2020
  2. eva2000

    eva2000 Administrator Staff Member

    44,186
    10,074
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +15,572
    Local Time:
    12:40 AM
    Nginx 1.17.x
    MariaDB 5.5/10.x
    If you chose HTTPS default for Centmin Mod Nginx site at creation time via self-signed SSL or letsencrypt SSL, then Cloudflare SSL needs changing from Flexible SSL to Full SSL. That is all there is to it.

    Then if you use a reverse proxy like Cloudflare, Sucuri, or Incapsula in front of Centmin Mod Nginx, you need to setup nginx realip to be passed onto Nginx.

    See Getting Started Guide step 5 and setting correct real ip via nginx module config at http://centminmod.com/nginx_configure_cloudflare.html. The tools/csfcf.sh cronjob mentioned below helps maintain the whitelisted CSF Firewall IPs, but you still need to setup nginx realip in your nginx vhost.

    If using Centmin Mod 123.09beta01 and newer, there's an added tools/csfcf.sh script to aid in this. Details at:
     
  3. FluxTux

    FluxTux New Member

    21
    5
    3
    Sep 22, 2019
    Ratings:
    +9
    Local Time:
    4:40 PM
    @eva2000 - thanks for patiently simplifying matters + the dokumentation pointer (y)

    Think it's the time delays that throws me off alongside information overload. Probably it would stick better if I worked with CMM every day, but this is a hobby thing...

    Somehow now got the site + cert back on track after reinstall + reverting the CF SSL setting to full...

    2 follow-up questions:

    1) I see SSL labs gives the site a B rating with the current setup. Reckon that in order to achieve an A rating I need Full (Strict) SSL enabled at CF alongside installing CF Origin cert+ key on the server? What gets me confused is that setup - guess chapter 5 in the start guide answers this(?)

    2) Do you know if a B vs A Cert rating impact anything? (e.g. in terms of SEO, browser warnings or whatever...)

    I will restudy the section you refer alongside my notes and hopefully come out a bit wiser... or perhaps just with a stickier memory and less tired/stressed :drowning::censored:
     
  4. eva2000

    eva2000 Administrator Staff Member

    44,186
    10,074
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +15,572
    Local Time:
    12:40 AM
    Nginx 1.17.x
    MariaDB 5.5/10.x
    SSL labs A+ needs just HSTS enabled but be careful you understand what enabling HSTS means and also believe now SSL lab needs TLSv1.0 and TLSv1.1 disabled Beta Branch - add SSL_PROTOCOL_MODERN variable in 123.09beta01

    In Centmin Mod, HSTS header isn't enabled by default as improperly enabling it and not understanding implications of enabling HSTS headers can cause you to DOS attack your own site - denial of service. For example, if you enabled HSTS with max-age = 1yr with include subdomains, it means you're telling web browsers only allow HTTPS version of your site to be accessed to visitors for every domain and subdomain *.domain.com and make it valid and enforceable for 1yr. Removing the HSTS after enabling won't help, as it's permanently cached in a web browser unless visitor clears their HSTS cache.

    Any subdomain or any non-subdomain without HTTPS SSL certificate will be denied access to your site for that 1yr period. So if you only had intention to enable HTTPS for say domain.com, www.domain.com and blog.domain.com but no intention for HTTPS for say host.domain.com, but you enable HSTS with include subdomain option - then you won't be able to access host.domain.com for that full 1yr period and any visitors won't be able to either as it's HSTS flag is cached in each visitor's web browser and you can't clear it on web server or your end. You effectively have DOS attacked your own site and prevented every visitor from accessing non-HTTPS host.domain.com for that 1yr. Sure you can get visitors to clear their HSTS browser cache as outlined below. But how many are tech savy enough and how do you notify those visitors if they can't access host.domain.com ?

    So I leave HSTS add_headers commented out/disabled in Centmin Mod created nginx vhosts by default and let end users like yourself decide if they want to enable HSTS.

    Same goes with other security headers, they have an entry left commented out/disabled in nginx vhosts created by Centmin Mod. But they have their own similar implications and consequences for enabling which may affect how your web site functions so you'd need to know what these security headers do and there consequences.

    See Enabling HSTS for SSL for specifics
    As accessing host.domain.com is usually reserved for stats and admin pages the Centmin Mod LEMP stack owner only needs to access, you can just clear your web browser's HSTS record for the domain.com and host.domain.com so the web browser no longer redirects from HTTP to HTTPS. I posted a thread at SSL - How to clear HSTS browser cache | Centmin Mod Community specifically for this :)

    With that said, if you know what these security headers do and their consequences, enable them.