My workplace allows me to use a Mac, but doesn't have much experience with them; their support is minimal if well intentioned, and generally as much harm as help. This includes installing antivirus software etc.   Recently, both Safari and Chrome have started showing the "This connection is not private" error with most off-site URLs. This is a recent change, and includes web sites I was able to access last week. I'm running MacOS 10.14.6 (18G87) with all updates.   This isn't a question of our IT deliberately blocking sites, as I can access them from my Windows computer (and in any case it includes sites that are clearly work-related).    In some cases, but not all, I'm able to bypass the warning by following the accepted answer for  (i.e. clicking through the "show details" buttons and entering my password), but this doesn't always work, and is pretty inconvenient besides.  I've also tried the other answers from that question, but these do not work. This is perhaps not surprising as that question refers to development work which involves self-generated SSL certificates, and my situation doesn't involve these.  I've also tried turning off antivirus software (insert scare quotes as you like), and that didn't help.   Note: When I look at the certificates on the problematic sites, I see the site's certificate but it's underneath a certificate issued by my workplace, and the browser shows my workplace's certificate as "Untrusted". I don't know how certificates work, but I'm guessing this is the problem and what I need to do is somehow make my browsers trust my workplace's certificates.   Any suggestions for working around this problem?
92847
I am doing development work. We have some test equipment that uses a self-generated SSL certificate. When I try to browse to the equipment in our lab, I get an error that "this connection is not private". However, the only 2 options available are "Show details" and "Go Back".  Show details just lets me look at the info on the certificate, which shows all of the expected self-signed details.  There is no way to tell safari to acknowledge the error and continue onwards. At least not obviously. How do I bypass this error and continue onwards? I'm using safari 11, on OS X sierra.
75262
When I get a captcha on Stack Overflow, I don't see the image or the input box with Firefox. I originally had the "HTTPS Anywhere" extension installed but still have the same issue when it's disabled (This caused issues previously when Google's SSL certs were expired for an old domain IIRC).  The requests to Google seem to be never-ending; browsing to the URLs that are still loading results in some pages of JavaScript, but no errors as you'd hope.  The screenshot was taken after the page had been open for more than 3 minutes, and I'm not sure why the GETs are still running. The request popup visible in Firebug is for "GET challenge?k=...."  When browsing to the same captcha page in IE, there are no issues.  I'm aware this could be an issue with my Firefox configuration, as opposed to the site, but would appreciate it if someone could verify if it's just me, and suggest a fix.  EDIT   While visiting the Recaptcha site, I can see a Captcha with no problems If I right-click the problem URLs in FF and Open in new tab, the pages load fine. From the fact that FB omits IP Addresses for the problem ones, I assume that it's not even opening a connection (nor perhaps performing a DNS lookup) Other sites that use Recaptcha seem to work fine (I picked 3 at random from Google)
21456
Background:   Story: A colleague of mine told me about  and it seems good to me. I am always trying to use tools which Mac OS X itself gives me, so I've given the Keychain a try. It seems satisfying, but I don't know how to tell Google Chrome to use my specific keychain. I need it to separate saved stuff for work and for private (syncing private to work, but separated from work data).  Stuff:   Google Chrome 21.0.1180.57 (Fully updated) Mac OS X Lion (Fully updated) OS X Mountain Lion (Fully updated)   Question:  How do I tell to Chrome to use a specific keychain and to save data from/to this keychain?
50895
This is quite messed up, I know. Let me explain it all.  I have a dynamic DNS set on my router. I verified that, after port forwarding, I can connect to desired application (if I run something on port 1337 and forward the port to appropriate machine I can connect to it from outside with no issues).  Now, if I connect my Macbook to VPN and run something as described above, it works as expected. BUT, if I connect my machine running Ubuntu Server 16.04 to the VPN and run something or want to connect by ssh, it fails. I forwarded port I'm using for SSH connection on router. I also tried hosting a web server, which also failed.  What can I do about this issue? This doesn't make sense to me.  About Ubuntu Server machine: it's a clean install with openvpn client and ssh server configured, no firewall running, iptables not edited, connected to router via ethernet.  EDIT: Here are the routing tables:
42509
As the question suggests: How to disable support of the SSL version 3 and set TLS version 1 as minimum (oldest) protocol supported in order to defend against POODLE.  One can test a browser with .  Basically, I haven't found a solution for Safari yet.
101089
When I go to any github.com page in Chrome, I get a big ugly error:  You attempted to reach github.com, but the server presented a certificate issued by an entity that is not trusted by your computer's operating system. This may mean that the server has generated its own security credentials, which Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications. You cannot proceed because the website operator has requested heightened security for this domain.  The same thing happens (in Chrome and with curl) when I go to  too. This strange problem started about a week and a half ago. Here's what I see when I click the broken lock icon in the address bar:   But gist.github.com works just fine:   It doesn't work with curl either:  Everything works fine in Firefox. How can I fix my root CA problem? Here's what it looks like in Firefox:   Update: I noticed that the first certificate in the chain is different in my broken Chrome/Safari as compared to Chrome on my other computer.   (There's no nasty red X anymore because I trusted it in Safari.) See how the issuers are different? What can I make of that?
62792
Every once in a while, someone comes to Meta to report a bug about something not working and it turns out that person is visiting one of the network sites over HTTPS/SSL. The problem has been growing since browsers started to outright block mixed content instead of showing a warning.  The usual answer is that HTTPS is not yet fully supported, and the person should try again using HTTP. Sometimes things get fixed, improving the situation a bit.  Is there a roadmap for full support? Partial support has been there for  now.  Is this actively being worked on? If not, what are the reasons to partially support it instead of disabling it completely to avoid these problems?
119168
I am running into a weird problem trying to disable HTTPS for one domain, but the other domain has HTTPS. They both are different websites running on a dedicated server, sharing the same IP address for the domains.  However, I have a domain that does not have a SSL certificate, but the other does. I want to disable HTTPS for the non-certified domain while leaving the other domain with HTTPS on.  I have two different separate vhosts in /etc/nginx/sites-enabled/,   domain1.org (no HTTPS)  server {      listen                      80;     server_name                 www.domain1.org domain1.org;     root                        /var/www/domain1.org;     index                       index.html index.php index.htm;      error_log                   /var/www/logs/domain1.errors.log;      [ ... ]   domain2.com (with HTTPS)  server {      listen                      443 ssl;     server_name                 domain2.com www.domain2.com;      # INCLUDE SSL CERTIFICATE     include                     sites-enabled/domain2_ssl_include;       root                        /home/domain2/www/www;     index                       index.html index.php index.htm;      [ ... ]   I've included a listener to the port 443 for domain1.org, but once I do that, I get an aborted error from Firefox saying (when accessing ):     This Connection is Untrusted      You have asked Firefox to connect securely to domain1.org, but we can't confirm that your connection is secure.   I opened the technical data, it appears that the domain1.org is using the domain2.com SSL certificate:     domain1.org uses an invalid security certificate.      The certificate is only valid for the following names:    *.domain2.com , domain2.com        (Error code: ssl_error_bad_cert_domain)   So I added this to domain1.org vhost configuration:  server {      server_name                 domain1.org www.domain1.org;      listen                      443 ssl;      rewrite ^ http://domain1.org permanent; }   Which still gets me prompted with the Firefox error.  Now... when I access to , I get an 400 error from nginx saying this:     400 Bad Request      The plain HTTP request was sent to HTTPS port   I am not entirely sure what to do, disabling the https with ssl off; has no effect. How can I actually disable HTTPS for domain1.org but not for domain2.com?  I am using Ubuntu 12.04 running nginx 1.2.6.
101625
Google Chrome 41.0.2272.118, Ubuntu 14.04    This is the second time I have had this error in the last week or so. Is this a bug on my part, or is there something up with the SE security certificate?  I've changed to bug because of :     No, it's something Stack Exchange would have to fix. Chrome is following the rules. But considering the whole meta.*.stackexchange.com dilemma is what's been holding up a lot of the HTTPS support, I doubt they're going to come up with any kind of fix for the www.*.stackexchange.com redirect problem. –  animuson♦
35347
Since installing Firefox 33 a "Secure Connection Failed" error is no longer  using the "I Understand the Risks" button - it's gone!  Is it still somehow possible to ignore certificate errors? (e.g. for lazy use in local environments) Error code: sec_error_invalid_key
99806
Could anyone suggest a modern way of generating self-signed certificates to be implemented on localhost, which would be accepted by Chrome and Mozilla?  I tried the openssl generation, however Mozilla complains that the issuer is untrusted.  Centos 7, nginx
77739
I purchased a certificate from  for my application, the problem is when I go to the url  I am getting the following message.   The certificate is not trusted because the issuer certificate is unknown. Error code sec_error_unknown_issuer. So people have mentioned that the intermediate certificate is need but I think that I have installed that as well as the main certificate.  This message seems to appear with Firefox and seems to be ok with the IEs  Any ideas?  Thanks
19534
When posting an HTTPS url like https://stackoverflow.com/..., it does not onebox in chat. For example:
120898
Here are the steps to reproduce this problem:   Be on a device where I am not logged-in to a meta site. Go to the main *.stackexchange.com site - Everything seems to work fine. Go to the meta.*.stackexchange.com site and click log in in the title bar - Page just refreshes without logging in. WTF?   Here is the workaround I have found to work:   Go to main *.stackexchange.com site and click on help=>meta Click through  about the . Log-in works.   I'm not fussy about whether my connection to SE is encrypted.  However, I do care that this problem created a barrier to my participation in meta.*.stackexchange.com.  I cared and knew enough to poke at this thing for five minutes and find a workaround so I could vote on a .  I doubt, however, that this is the case for most users.  It concerns me that participation in meta is being filtered by a technical problem.    I use chrome as my browser, and my google account to authenticate.  The problem exists on both Travel and English se.com on both a Windows 7 and 8.1 machine.     seems similar.  However, the symptoms are different in two ways: In my case no login page is ever presented, and I'm not using OpenID.
71667
Safari forces a redirect to the https version of a site I previously visited via https.  However, the https site no longer works and there is no way to prevent Safari form trying to load it.    Here is a related Apple Forums question,
92185
Learning postfix, I've set up SSL on my server and everything is working.   Google/Gmail was saying Untrusted TLS connection established until I downloaded an Equifax SSL CA bundle and added it to my CA bundle. Now it says trusted connection whenever sending an email to Google.  So now I'm trying to do the same for Yahoo and Outlook365 connections. The connections say Untrusted TLS connection established whenever I send them emails.   Am I going about this the right way? by downloading CA bundles and putting them in my CA bundle? I've tried ssl_CA_path and just putting them in there, but that didn't work, only smtp_tls_CAfile seems to work.   Centos 6.7 postfix 3.2.2
80473
When I visit , any web browser I use considers the URL to be secure.  This is what Google Chrome shows:    Normally, when I try to visit an HTTPS site via its IP address, I get a security warning like this:    From my understanding, the site certificate needs to match the domain, but the Google Chrome Certificate Viewer does not show 1.1.1.1:     says:     No - we no longer accept certificate requests for either intranet names or IP addresses. This is an industry-wide standard, not one specific to GoDaddy.   (emphasis mine)  And also:     As a result, effective October 1, 2016, Certification Authorities (CAs) must revoke SSL certificates that use intranet names or IP addresses.   (emphasis mine)  And:     Instead of securing IP addresses and intranet names, you should reconfigure servers to use Fully Qualified Domain Names (FQDNs), such as www.coolexample.com.   (emphasis mine)  It's well after the mandatory revocation date 01 October 2016, yet the certificate for 1.1.1.1 was issued on 29 March 2018 (shown in the screenshot above).    How is it possible that all the major browsers think that  is a trusted HTTPS website?