Recently I discover letsencrypt which is awesome project, and it basically allows you to get ssl certificate for free.
I manage to setup my server and domain with their certificate, everything work great and my site showed the https in green which was great.
Then I connected this domain to cloudflare, which is another great solution, for many web problems.
Once my name servers were changed to cloudflare name servers the https stopped working.
:(
I am not really sure what is the root of that issue, but I manage to fixed it with a little bit of luck, so decided to write here the problem and the solution who worked for me in case other will encounter this issue in the future.
On cloudflare
https://www.cloudflare.com/a/crypto/yourdomain
default settings for ssl is full, once I changed it to
strict https start working again like charm.
2 days after I had the same issue, I changed it back to full from strict and then it worked again so I am confused and not sure if my answer here is good.
you need to use certbot when you're already using cloudflare.
check this link
So before you run the certbot command try this first export LC_ALL="C"
Then if you're on apache change the command to this
./certbot-auto certonly --webroot --webroot-path /var/www/html/ --renew-by-default --email email#host.tld --text --agree-tos -d example.tld -d www.example.tld
/var/www/html/ = where your webroot path for the domain is located.
I hope this helps..
I've faced the same issue that CloudFlare said there is a 526 error.
I could solve it by adding
SSLCertificateChainFile "/etc/letsencrypt/live/DOMAIN/chain.pem"
to the apache hosts config, since Apache < 2.4.8 needs the chain (see http://letsencrypt.readthedocs.org/en/latest/using.html)
Related
My Node.Js Bitnami Lightsail instance had its frontend code at /opt/apache/htdocs and http://example.com was working perfectly pointing to that directory (my backend located under opt/projects).
After executing Certbot LetsEncrypt my domain is now pointing to a different folder /var/www/html
Please advise on:
In certbot instruction page I choose Apache for "My HTTP website is running", there wasn't a Bitnami option, was that the right call?
Is this the right configuration and just move my code to html folder?
Does my backend code has to move too? if so where?
Any other well-known issues that I might face?
Cheers.
Bitnami Engineer here,
We do not have any guide to configure certbot and Bitnami, but we have a guide that helps you configure the Let's Encrypt SSL certificate using lego. We have a tool that configures everything so you do not need to worry about editing the Apache's conf files or setting the renew process.
sudo /opt/bitnami/bncert-tool
You can learn more about it here.
In case you want to manually create a SSL certificate, you can also run the lego tool directly
sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run
You will later need to configure the Apache's conf files to use that new certificate file. You can learn more about it here
Note: If you used certbot and it modified the Apache's configuration, you will need to undo those changes to use the proper folder. You will need to review the /opt/bitnami/apache2/conf/httpd.conf, /opt/bitnami/apache2/conf/bitnami/bitnami.conf and /opt/bitnami/apache2/conf/vhosts/* files
I have been trying to achieve wildcard SSL for my app where I need HTTPS for all the dynamic subdomain and I have been trying almost all the tuts found on the internet and almost all way is either giving redirect loop or not working. I am trying this for almost 2 days now and have totally no idea how to go forward. I tried it using certbot doing acme-challenge, DNS Cloudflare plugins but nothing worked for me. Please guide me.
Let's Encrypt supports wildcard SSL certificate only via DNS-01 challenge.
Yes. Wildcard issuance must be done via ACMEv2 using the DNS-01 challenge. See this post for more technical information.
If you use dehydrated, I can recommend cfhookbash, which is a hook for dehydrated.
./dehydrated -c -d *.example.com -t dns-01 -k '${PATH_WHERE_YOU_CLONED_CFHOOKBASH}/cfhookbash/hook.sh'
A few days ago, Chrome started redirecting all of my vHosts in Wampserver to https. Everything was working fine until a couple days ago, then one day I logged on to work on my site and Chrome said that the site couldn't be reached, even though I used the same URL i always did in the past. Wamp is running as well as Apache and MySQL and none of those services have any errors in the error log.
I have already tried removing the domain(I use a fake .dev extension for my local sites) with chrome://net-internals/#hsts but that didn't do anything. I also tried installing SSL to see if Chrome would detect it as a secure connection... nothing. I even tried reinstalling Wamp completely(even though the vHosts work fine in other browsers) and nothing changed.
The only thing that works in Chrome is accessing the sites via http://localhost/site. The redirect to HTTPS happens for all of my Apache vHosts. I've googled and googled and can't find anything that actually fixes the problem.
Chrome v63 forces .dev domains to HTTPS. The Internet Engineering Task Force RFC2606 specified what top level domains should be used for local development, and .dev isn't on that list.
Google owns the .dev top level domain and automatically redirects all .dev domain names to an HTTPs version of the site via preloaded HSTS.
With .dev being an official generic top-level domain (gTLD), we're better changing our local development suffix from .dev to something else, even if there are other solutions (e.g. https with self-signed certificates). So you should use .test, .example, .invalid or .localhost as your local development TLDs instead.
I can't improve the answer of #benedikt, as it is correct. There are good temporary fixes:
typing "badidea" on the warning page, this might not work if you have SSL set up (hacked together) locally. It bypasses the warning, but my local SSL isn't setup correctly and shows another local site.
narayon also suggests a link to a chrome forum, which I haven't tried.
My workaround was to update all my ".dev" development TLDs to ".d3v"
Still short enough to type quickly, descriptive, and probably future-proof.
I have found a quick work-around that worked for my needs and may help someone else.
I use Browser Sync when developing and I just set the proxy argument to "testsite.dev" and it will serve up correctly in Chrome.
Here is the command I am using:
browser-sync start --proxy "testsite.dev" --port "3000" --files "./**/*.*"
I too use the .dev extension and will change to some other domain in the future but for my existing .dev sites, when the privacy error shows up, click anywhere on the screen and type 'badidea' and chrome will redirect you to the site. It works!
Solution 1 - choose a reserved and future-proof gLTD like .localhost or .test
Edit your hosts file (for Windows it is C:\Windows\System32\Drivers\etc\hosts)
127.0.0.1 testsite.localhost
Solution 2 - install a self-signed certificate for .dev
Create the certificate. Open Powershell as Admnistrator and run:
P.S. Make sure to install mkcert first
C:\Users\John> mkcert *.testsite.dev
This will create a wildcard certificate that will work for all .testsite.dev sites
Copy these keys from C:\Users\John to C:\xampp\apache\crt\testsite_dev (create the crt folder if it doesn't exist)
Add entries in your C:\Windows\System32\Drivers\etc\hosts file
127.0.0.1 testsite.dev
127.0.0.1 www.testsite.dev
Open your C:\xampp\apache\conf\extra\httpd-vhosts.conf and add an entry
<VirtualHost *:443>
DocumentRoot "C:/xampp/htdocs"
ServerName testsite.dev
ServerAlias www.testsite.dev
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
SSLEngine on
SSLCertificateFile "crt/testsite_dev/_wildcard.testsite.dev.pem"
SSLCertificateKeyFile "crt/testsite_dev/_wildcard.testsite.dev-key.pem"
</VirtualHost>
Restart Apache
(Extra) step - make your OS & browser trust self-signed certificates, otherwise it won't work
I chose to force https on my server when setting up let's encrypt, not realizing what a NIGHTMARE it would cause for my Node.js WebSocket server. Nothing that I've found online works to get a secure WebSocket connection up and running. (Probably because I'm using Apache for everything aside from WebSockets)
So I've decided to just disable SSL site-wide. I don't have any real use for it as my server is strictly for development anyway.
I've tried the method here But Apache reports that the site is already disabled. So I cleared the cache on my browser and even tried to visit the site incognito to no avail.
I also looked at the instructions here but NONE of my site-available contain the lines that are mentioned.
Then I saw this post but my apache2.conf file did not contain the lines he mentioned either.
I'm puling my hair out.
If anyone else has this issue, here's what I did to solve it.
I saw a configuration file named <sitenam>-le-ssl.conf in /etc/apache2/sites-enabled So I tried a2dissite <sitename>-le-ssl.conf
But Apache said "the file doesn't exist"
So I copied that file to my home directory with cp <sitename>-le-ssl.conf ~(AND YOU SHOULD TOO! just in case...)
Then I deleted that file with sudo rm <sitename>-le-ssl.conf
Then, restart apache with sudo service apache2 restart
Finally, clear the cache on your browser and visit your site. Everything should be back to normal now.
No idea why letsencrypt set up my server in such an odd way. It didn't follow ANY of the standards that others said it should.
Hope this helps someone in the future.
I recently successfully installed Letsencrypt, and my site seems to work well with https. When i visit it e.g https://example.com, no errors/warnings appear. However when i visit it with https://www.example.com, (including www) in all browser I get some sort of warning, for example, in chrome:
Your connection is not private
Attackers might be trying to steal your information from
www.example.com (for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID
And in opera:
Opera cannot verify the identity of the server "www.example.com", due to a certificate problem. The server could be trying to trick you.
My server runs apache and https works wonderfully when not www. In /etc/letsencrypt/live/www.example.com/ I have:
cert.pem chain.pem fullchain.pem privkey.pem
Would appreciate any help and do ask if you require further detail. Hope this helps others too.
This is saying the cert is not valid for www.example.com.
Could be several reasons for this including:
You didn't specify this when creating the cert and only asked for example.com. Though weird that LetsEncrypt has put it in the www.example.com directory, suggesting you did do this right.
You made a typo in the domain name.
You included the protocol (http/https) in the domain name and/or the port (443). These should not be in the cert request and just the domain name.
You have a separate cert for example.com and www.example.com and have only one configured in Apache. Most sites use the same cert for both and have both versions valid for the domain.
Probably best to view the cert to rule out some of these. This can either be done in the browser by clicking on the green padlock when viewing https://example.com and/or running this command:
openssl x509 -in /etc/letsencrypt/live/www.example.com/cert.pem -text
You can also use the https://www.ssllabs.com/ssltest/ online tool to view your SSL setup (in fact I'd recommend to do this anyway!).
It might be late but the problem is there because you didn't mentioned www.exemple.com in the certbot setup.
to add the domain to your certificate just run this command
sudo certbot --expand -d www.camelges.com
then restart your apache server
if you are on ubuntu service apache2 restart
Reference: https://certbot.eff.org/docs/using.html#re-creating-and-updating-existing-certificates
From their post here:
Can I get a certificate for multiple domain names (SAN certificates)?
Yes, the same certificate can apply to several different names using
the Subject Alternative Name (SAN) mechanism. The Let's Encrypt client
automatically requests certificates for multiple names when requested
to do so. The resulting certificates will be accepted by browsers for
any of the domain names listed in them.
If your common name is example.com you will need to set a SAN as www.example.com when generating the certificate request.
Adding to the points from BazzaDP, (From my own experience).
5) if you have virtual configuration files where ServerName is same but ServerAlias is different then you will be getting same err, hence you should change ServerName.
You need to generate certificate for both URL's, by example:
sudo certbot --apache -d mydomain.com,www.mydomain.com