I recently bought the SSL certification off GoDaddy in India for my domain anrweb.com
The only problem is that the https:// version throws up an "SSL connection error" on Chrome & Firefox. I had incorporated a web.config file that redirects all http requests to https, but that caused the website to not load at all!!
I'm weak in these server-side setups and was looking for help online but was unable to find any resources. Godaddy has no clue whats happening either.
Can someone tell me if I need to make any other changes to my DNS records or any other back-end updates to reflect the SSL installation.
BTW, my domain services, hosting & SSL are all from GoDaddy
What version of Firefox and Chrome are you using? I'm able to access the site on Chrome 40.0.2214.91. The SSL Labs test https://www.ssllabs.com/ssltest/analyze.html?d=anrweb.com does not indicate any handshake errors although your choice and ordering of cipher suites could use some cleanup. https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html has the recommended SSLCipherSuite value.
Solved.. Turns out I had to point my DNS to the newly issued static, permanent IP address. Works just fine now.
GoDaddy should've mentioned this during the setup, but figured it out anyway.
Thanks a ton
Related
I am running a twiki installation on a Centos9 server that is accessible from our own network via http://twiki.
It is not accessible from outside.
I regularly get the warning SEC_ERROR_UNKNOWN_ISSUER (Firefox) or NET::ERR_CERT_AUTHORITY_INVALID (Internet Explorer, Edge). Of course I can ignore the warning, but after a while it pops up again and that's quite annoying for me.
What can I do to prevent this? I don't actually need https, http would suffice, but I always get redirected to the https version. Is this something the browser does? Or can I configure the web server (Apache) to prevent this?
To be honest, I'm not really a webmaster or network expert. I just need to get the Twiki working. What I've found out so far is that I'm getting the warning because I self-signed my SSL certificate and there is no known trusted author. I also can't get a signed SSL certificate because my server doesn't have a domain like .com or something.
If possible, I would prefer a solution on the server so that each user doesn't have to configure their browser
I have a digitalocean One-Click Ubuntu Wordpress Droplet with a NameCheap domain.
I've never done anything with SSL before so I followed a tutorial (https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04). Once I made it to the end with no issues, I realized that it was a self-signed certificate and didn't remove the warning that browsers were giving and that I had to purchase one from a provider. Since my domain is through NameCheap, I went through them (Comodo?) and followed their linked tutorial for the setup (https://brettdewoody.com/how-to-setup-ssl-certs-with-digitalocean-and-comodo/).
I made it through that and browsers were bringing up an error saying that it was a self-signed certificate and it could be a problem. I went back through both tutorials and checked my stuff and tried to remove what I could of the original part. After blindly finagling things for a few hours, my site receives an A+ from this ssl checker (https://www.ssllabs.com/ssltest/analyze.html?d=vc2online.com) but browsers refuse to connect to the site (vc2online.com).
I don't even know where I need to start to get this to working properly.
Currently your issue is that you have 301 redirect from vc2online.com to www.vc2online.com but unfortunately your ssl certificate is only for vc2online.com, not www.vc2online.com.
You enabled HSTS so going backward won't be easy.
The quickest way to solve it is by using let's encrypt instead the comodo certificate.
You can use certbot to fully automate the process. You will find out it is much easier (and cheaper) than comodo paid certificate
P.S. I think this question should be asked in super user / server fault.
Here is my story
I have Amazon EC2 with Tomcat 7 hosted at an Elastic IP as
http://ec2-XX-XXX-XXX-XX.us-west-X.compute.amazonaws.com:8080/webAppX
http://ec2-XX-XXX-XXX-XX.us-west-X.compute.amazonaws.com:8080/webAppY
http://ec2-XX-XXX-XXX-XX.us-west-X.compute.amazonaws.com:8080/webAppZ
Then I bought a domain at 1&1 as domainXYZ.com
I bought SSL from sslmate.com for the domainXYZ.com
Now, my confusions come
We follow instructions from sslmate.com and do the same for httpd from Amazon EC2 but when I access https:// , the browser says errors as below
Your connection is not private
Attackers might be trying to steal your information from ec2-XX-XXX-XXX-XX.us-west-2.compute.amazonaws.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is ec2-XX-XX-XX-XX.us-west-2.compute.amazonaws.com; its security certificate is from www.domainXYZ This may be caused by a misconfiguration or an attacker intercepting your connection. Learn more.
Could you please advice me what things I missed or wrong.
Question #2: How come I re-direct from 1&1 to ec2-XX-XX-XX-XX.us-west-2.compute.amazonaws.com?
I do see we have options such as FramRedirect, or A record by changing DNS using IP
But I'm not sure which one I should use for HTTPS will be handled.
Thanks,
Nghia
You are making your life unnecessary difficult.
Just buy the domain using AWS Route 53 and link it to your Elastic IP.
As soon as your instance is reachable via the domain set up a certificate for free using LetsEncrypt and EFF's certbot.
Finally open HTTPS port via AWS console security settings.
My ssl certificate has expired and I have created a new one using Startssl. I have followed the steps for Nginx server that I have found in the FAQs from Startssl but, although the paths to the certificate and the key are correct, when I try to load the website with any browser it always gets the old certificate instead of the new one. Do anyone knows what can be happening?
Thanks!
March 22th UPDATE:
I have found something of what is happening: we have 2 web servers in AWS and a Load balancer. I have seen the load balancer has also the ssl certificate and I guess I have to update it too. I have done it and now the new certificate is in usage. But I still see an error: the server cannot check my domain because my certificate comes from one of my subdomains. When I created the certificate in StartSSL there was an step that asks me for a subdomain. It said the certificate will be for the domain and subdomain, but now I'm getting this message. Any idea?
I have found the answer:
When StartSSL asked for a subdomain when I was following the steps to get the new certificate, I was indicating one of my real subdomains. If I set as subdomain "www" everything works. So I wanted to share my experience with everyone hoping it helps:
First: when you are asked for a subdomain in StartSSL, set it as "www".
Second: If you are using AWS and you have a load balancer, don't forget to update the SSL certificate in the load balancer, using the AWS NETWORK & SECURITY -> Load balancers option (Listeners tab).
Hope it helps.
Thanks for reading and trying to help me.
I've been getting reports of users visiting our site getting "this certificate is not trusted" errors when visiting our site via https. I don't seem to ever have any problems, but two separate people on my team have gotten this error randomly when they're on a different wifi network other than the one at our office. They don't have the same problem at the office.
I read up on intermediate certificates but this seems to be just a browser thing, not a network related issue.
I have an SSL cert from GoDaddy, it's on a Rails app running on nginx + unicorn.
Does anyone have any other ideas why this might happen? I'm pretty stumped.
Be sure that everyone is using the same host name.
I've seen this issue if there are multiple server aliases, for example www.foo.com and foo.com. be sure the one without the SSL certificate is redirecting traffic.
From home someone was using a different hostname, because of browser history. Fixing up the redirects fixed the problem.
The error should be tied to your browser not trusting the intermediate cert and not related to wifi. Please make sure the browser trusts the intermediate and root ca trust of GoDaddy.