So I have got an application on openshift and I am trying to enable SSL on there. I already have an SSL cert from my previous host which is with Trustwave and seemed to work fine.
So I have setup an alias for my-domain.com and have put a CNAME redirect on the domain provider to openshift and that works fine. Now I was provided a zip file full of different file formats for the cert:
my-domain.com.cer
my-domain.com.der
my-domain.com.p7b
my-domain.com.pem
chain.cer
I have got a private key as well in a .pem file, and it seems to all setup fine, using the my-domain.com.pem, chain.cer and my-private-key.pem. However if I then go to any of the SSL analysis sites they all say the same, that there is no intermediate cert, and it even seems to think I am not using a trustwave cert, which I most certainly am. I know openshift uses SNI so I am not really to worried about the *.rhcloud.com issue, but I am baffled as to why it thinks my cert is not from trustwave (when it is) and why it cannot find intermediates.
Most browsers other than FF dont care about this and work fine showing the padlock, but Firefox shows the invalid SSL screen and warns the user rather than showing the site.
I have tried going to the trustwave site and downloading their intermediate certs dvca2.crt but even trying that still gives same issue.
I am a bit baffled as to why it doesnt work, I have tried the other file types in the zip file such as the my-domain.com.cer but still same thing. So I am out of ideas and wondering if anyone else has had similar issues or knows what could be causing it.
Ok solve it after lots of searching, and Trustwave still reports it as wrong but all browsers seem to accept it.
So I got the main cert file (I was using my-domain.com.pem) copy and paste the contents into a new file (something like combined.pem) then open your intermediate file (chain.cer for me) and copy and paste this into the end of your combined file, so it should look like:
-- Begin Cert
...
-- End Cert
-- Begin Cert
...
-- End Cert
Then upload this new combined file as your main cert file to openshift, ignore the chain file and add your private key. Should all work now.
Related
I am looking a solution for hours but can't find any. I am using letsencrypt ssl via certbot.
My domain is ektaz.com when I check certificate on browser it says
Expires: 8 November 2021 Monday 16:24:33 GMT+03:00
When I check it from server side with certbot certificates I get result as
Expiry Date: 2021-11-08 13:24:33+00:00 (VALID: 39 days)
But all browsers says certificate is invalid I don't understand why.
Also I have renewed this certificate many times using certbot renew I had no issue so far. I have cleared all cache and tried result is the same. I restarted apache many times. Even restarted server but nothing changed.
Server OS : Ubuntu 20.04 LTS
Your certificate is likely not invalid at all.
There is a simple fix. I'm using nginx configuration style for this example:
ssl_certificate /usr/local/etc/letsencrypt/live/domain.com/cert.pem;
Lines like that need to be replaced by lines like this
ssl_certificate /usr/local/etc/letsencrypt/live/domain.com/fullchain.pem;
Then refresh your server's configuration.
This problem is popping up all over the place, including with both small and large websites.
The root cause is older tutorials for configuration of webservers that served the cert.pem file (because it worked) rather than the fullchain.pem file which makes sure a browser gets the full chain needed to validate the certificate.
Unfortunately, Apple, Mozilla, and some others have dropped the ball and are still using the same intermediate certificate (IdentTrust DST Global Root CA X3) which expired yesterday afternoon at 2:21:40 pm CST to check certificates that were using it before. iOS 15.0 (19A346) is the only released Apple software version that is automatically using the new intermediate certificate even when the server doesn't send the full chain.
The actual intermediate certificate being used by the server is issued to R3 by ISRG Root X1, but unless you configure your server to explicitly tell this to browsers by using the fullchain.pem within the server configuration, then sadly many software companies have dropped the ball and don't do it right on their own.
But once again, this is an easy fix. Just make that slight change to lines in your server's configuration file "cert.pem" -> "fullchain.pem" and you should be fine.
And there's no reason not to keep on using the fullchain.pem file permanently. In fact, even prior to this situation, various networks (college campus WiFi networks are notorious for this) will screw up your certificate's chain of authority unless you use the fullchain.pem file anyway. Let's Encrypt even recommends this now as the only proper way to configure your web server to use certificates.
I created a self-signed certificate in a local pc and now I can't access to the localhost showing the following error in both chrome & firefox. There is no option to accept the risk and continue.
I tried removing the generated cert and key files but the issue is still there.
Is there way to rollback that change? Or any other way to continue.
OS: OpenSUSE Thumbleweed
HSTS is blocking you, so clear HSTS config in used browser for used domain (locahost). Random blog post how to do that: https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
When using web2py, it asks a single ssl certificate file.
But what I got from Comodo are two files, one .crt file and one .ca-bundle file.
I tried with using only provide the .crt file when setting up web2py, in the beginning it works. But when I go to my website another day, it shows "This certificate cannot be verified up to a trusted certification authority."
My suspicion is that this is related to the case of not using the .ca-bundle file. So anyone knows how to use both files in web2py settings?
Finally got it working!
It turns out to be the Web2py 'One step production deployment' script is not complete. It leaves out the 'SSLCertificateChainFile' option when it configures the Apache server.
So by adding this line:
SSLCertificateChainFile = path_to_your_ca-bundle_file
Below the line 'SSLCertificateKeyFile /etc/apache2/ssl/self_signed.key' will do the work.
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
via Namecheap I have my SSL certificates (POSITIVESSL Comodo) which run on my Nginx webserver to offer https to my clients. This worked like a charm until my certificate expired.
Now I tried to install a new certificate, but whatever I try, the old one is being loaded.
What I did.
Removed all the old certificate files (.key, .crt, .csr)
Using this tutorial creating a new key files.
Entered that file into the Namecheap SSL panel to generate new SSL certificates (which arrived, and show to be valid from 11/26/2012 to 12/26/2013.
Go to my certificates directory, put in the 3 .crt files I got.
Using this tutorial i bundled all the .crt files into 1 .pem file.
Check my nginx.conf to confirm all the paths to the .key & .pem file are correct
Restart nginx
I even tried to change the file names, to ensure they cannot conflict with the old ones, but still my old certificates are being loaded. I have used tools like: http://www.digicert.com/help/ to test the certs, also there the old ones are still being loaded.
Apart from Nginx, should I restart anything else to ensure the new files are being loaded correctly?
Issue has been resolved, the DDOS protection proxy also needed to be updated.