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.
Related
I recently got a wildcard SSL cert for our main domain -- let's say it's mysite.ca
Under it, we have several subdomains on different servers
For one subdomain one.mysite.ca, everything is working except for a few subdirectories, for example, one.mysite.ca/folder/something, keeps showing an SSL cert error. When I look into the specific page, it looks like it's still using an old certificate that has been canceled, not the new wildcard cert.
I am getting confused because I'm under the impression that a wildcard SSL cert for the main domain will protect all subdomains. Well, my confusion is mostly due to my lack of understanding I suppose.
More interestingly, this issue got magically resolved with a system upgrade. I am not sure why this happened in the first place, or why it was resolved. Any insights? Very curious to learn...
Thank you!
I'm not sure what actually happened in your case since we only have your interpretation of the issue. But based on how HTTPS works it is not possible to have path dependent server certificates:
The path is part of the HTTP request and the HTTP request is send over the already established TLS connection. This means the path is only available to the server after the TLS handshake is already done. Thus it cannot be used to pick a server certificate.
Maybe there were some cached permanent redirects to a different domain with different certificates, i.e. the expected domain was not actually contacted since it was already known that it would redirect to somewhere else. But this is just speculation.
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.
this one is driving me mad - hopefully anyone of you can help.
I ordered a cloud server with intention of running multiple customer sites on one server/one ip. Everything is working fine so far, but Im having troubles with SSL.
I added 2 Domains (Domain a, Domain b) via Plesk Panel and installed basic ssl certificates which are working perfectly fine. Both Domains can be accessed via https:// and in the broswer both certificates are shown as valid / secure
Problem: Im getting SSL Issues / Warnings when connecting to the domains mailboxes -> to secure the Plesk Panel a self-signed Certificate was pre-installed.
When I exchange the Plesk self-signed certificate to a certificate for Domain a, Domain a mailboxes are working perfectly fine - but not for Domain b. (obviously). What certificate do I need to install to secure the Plesk Panel and which does not cause any problems with all underlying Domains & their mailboxes?
Will creating a certificate for the servers IP address will do the trick? Is this accepted, even possible or will it result in another warnings? If yes, do I need to create a certificate for xx.xxx.xxx.xxx or xx.xxx.xxx.xxx:8443?
Or is there any other option for running multiple domains on one shared ip?
Any help/guidance is very much appreciated!
Thanks!
Did you mean something like mail.domainb.com or autodiscover.domainb.com for mailbox? Then make sure you have valid SSL certificate for them also not only for mail domain. As far as I know you would not be able to get third-party certificate on IP addresses.
Sorry if I have guessed wrong.
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
Here's a possible scenario.
Let's say I have a website "https://www.mywebsite.com" and there is a valid SSL certificate purchased for this domain.
I want to "mimick" this website on my LOCAL machine for a testing purpose.
So let's say I set up a locally-configured "https://www.mywebsite.com" (which is in essence https://localhost/mywebsite or something similar).
Would I be able to re-use the SSL certificate on my local testing website?
You can re-use your SSL certificate if you configure your DNS so that your test machine is the same domain name as server, which is probably a bad idea.
You can also re-use it on your test machine if you don't mind clicking the box "accept this whacked out ssl cert"... So I suppose that the answer is technically yes, although I wouldn't personally do it.
It depends what you are trying to test and why you need a certificate for testing.
If you use the certificate, it will correctly encrypt connections using SSL, but any client will get a certificate mis-match error. If you use a self-signed certificate instead, most clients will give you a warning about that, so it might be just as annoying or not.
If you are testing, for instance, a deployment script to make sure everything gets installed in the right place, it will work. If you are testing to make sure your code correctly redirects a non-secure connection to a secure one, it will work.
If you want to test the your website for functionality, usability, bugs, etc. then your testers will likely complain about the certificate warnings or errors, and you're probably better off doing something else.
I am not sure since the SSL certificate is bound by the domain name that was registered with the certificate. But you may be able to dupe the certificate by editing your hosts file to change localhost 127.0.0.1 to be mysite.com 127.0.0.1, ...in theory at least...if not this is a question for serverfault.com.
Hope this helps,
Best regards,
Tom.
You can't use it since the SSL cert is tied to the domain www.mywebsite.com unless you do a bit of trickery.
You can put an entry in your hosts file saying that domain is at 127.0.0.1, but that's not ideal as you could no longer reach the website.
If you just need a valid cert to test with, then a better alternative is to self-sign using the IIS Resource Kit.
I'm no expert on DNS, but this would introduce a pretty major vulnerability.
Basically if this was allowed, DNS poisoning could be used defeat the whole purpose of third party trust.
Think about it:
I infect your computer so that when you go to www.amazon.com it resolves www.amazon.com to a different domain. That domain uses amazon's ssl cert to fool you into thinking it's legit, so you send me your credit card information.
So, the answer to your question is, no you can't do this. You will still get errors, My guess is that somewhere on the verfication chain, it compares the domain that initiated the request with what its internal dns resolves the domain, to verify there is a match.
As others have said, you can test SSL with a Self Signed Cert, you just have to instruct your testers to import the cert, or go through the trouble of building your own trusted CA, and have testers add that CA as a trusted CA.
There is no point in stealing another sites SSL Cert.
Of course you could use the vulnerability in MD5 to create your own valid SSL cert.
http://www.digicert.com/news/2009-01-05-md5-ssl.htm