Keywords: WordPress Multisite - Google Cloud Platform - Technical issue - Secure Connections (SSL/HTTPS) bnsupport ID: 733563d9-66ad-85cf-efa0-3f65c7e9f769 Description:
the tool was run successfully without warning, but afterward, the website can not be accessed.
When running the Bitnami HTTP configuration tool, you accepted to force the redirection to https and www. when accessing your site. I think you configured WordPress to use the non-www domain and that’s why you are getting a redirection loop (Apache is redirecting to https and www and then WordPress says that the user should access using the non-www domain). Let’s disable the www redirection to fix the issue. Please edit the /opt/bitnami/apache2/conf/bitnami/bitnami.conf file, it should look like this
@jota Finally I had solved the problem by adding the sub domains one by one into the domain list while running the tool, but this is not necessary while I installed Let’s Encrypt Certificate manually before.
does this mean i will need to run the tool every time when I want to add a new sub site?
I don’t know how you configured the SSL certificate in the past. AFAIK, you can use wildcards when setting the domains, that way you will generate a certificate valid for all the subdomains you have. You will need to set johocen.com as primary domain and then *.johocen.com.
If you use johocen.com only, you will only generate a certificate that is valid for that domain but test.johocen.com is not included in the certificate and that’s why you obtain the error message about the site being insecure.
We are using RPA for adding new site, so it’s important to avoid too many additional procedure such as running HTTPS configuration tool for every new site. (It will be nice if you remind that wildcards is not supported for this tool.)
If we don’t want to use this tool anymore, only to remove the renew command sudo crontab -l will be enough to go back to the original status ? or should we remove all this tool related folders and files?
In the Troubleshooting for this tool, there is
Manually Revoking An Existing Certificate
If we don’t want to use this tool anymore, do we need to change these 2 lines?
The alternative approach uses the lego tool. It’s a client written in go that allows you generate Let’s Encrypt certificates. It does support other challenge types like the DNS one that allows you to use wildcards
I mentioned that our guide uses the TLS challenge so you will need to use the DNS one when running the lego tools.
Well, our tool takes care of creating the SSL certificates, configuring the webserver and configuring the renewal process. I told you to remove the line in the cron job to not to perform the renew (because you will use a different tool to generate the new certificates and configure the renew process so you will avoid problems when removing the existing cron job) but the certificates will be kept in the instance. Please note that they are just files that contain the information about your domain.
Ok, can you check the bitnami’s crontab?
sudo crontab -l -u bitnami
If you revoke the certificates and use the dummy ones we include, you will run into the security issues that you got before. I’d keep the certificates while you generate the new ones using the wildcards. This way, you will be able to access your current domains using HTTPS. Once you have the new certificates with the wildcard, you can change the Apache’s configuration to start using them.
First of all, remember to remove the lego line in the crontab when we finish creating the new ones. You can simply edit the file by running this command
sudo crontab -e -u bitnami
Note: we were using the -l option previously to list the lines but the -e option allows you to edit the file.
You are missing some parameters when running the lego command. You will need to set the provider and provide the required information
Credentials for DNS providers must be passed through environment variables.
To display the documentation for a DNS providers:
$ lego dnshelp -c code
All DNS codes:
acme-dns, alidns, auroradns, azure, bindman, bluecat, cloudflare, cloudns, cloudxns, conoha, designate, digitalocean, dnsimple, dnsmadeeasy, dnspod, dode, dreamhost, duckdns, dyn, easydns, exec, exoscale, fastdns, gandi, gandiv5, gcloud, glesys, godaddy, hostingde, httpreq, iij, inwx, joker, lightsail, linode, linodev4, manual, mydnsjp, namecheap, namedotcom, namesilo, netcup, nifcloud, ns1, oraclecloud, otc, ovh, pdns, rackspace, rfc2136, route53, sakuracloud, selectel, stackpath, transip, vegadns, versio, vscale, vultr, zoneee
More information: https://go-acme.github.io/lego/dns
You can either review the lego documentation, ask in its forum to know more about that, follow the approach of this other user who followed the Lightsail documentation (please note that you are using Google) or use the same method you used in the past to generate the certificates
Thank you for the explanation, but sorry for my poor English with not enough technical background, still not quite sure after studying all the documents. Please correct me if there is anything wrong for the steps I’m going to do: