Has anyone had issues with Lets Encrypt SSL certificates with Avast Internet Security?
We are getting some reports that Avast Internet Security is blocking the connection.
This is a screen shot from a clients computer (yes old windows, but still an issue regardless).
We have also had reports on a totally different server, hosted by a totally different company as well. Same error, but this time on a mobile device using chrome.
Has anyone come across this yet?
This might be related to one of the Lets Encrypt certificates expiring on September 30th, 2021.
Here's another question that talks about this: LetsEncrypt Certificate invalid/expired when seemingly not in PHPMailer, TLS, Openssl, file_get_contents, Sep 30 2021
Related
In my work computer, Firefox always gives me the "sec_error_unknown_issuer" error. This happens only on all HTTPS sites.
I have browsed Mozilla's support forums and understood that this is most probably caused by a software that performs an HTTPS scanning. The software presents its "fake" certificates to Firefox and hence, Firefox says that it does not know the issuer of these certificates.
However, I don't know which software is performing the HTTPS scanning and presenting its "fake" certificates to Firefox.
Is there a way to determine which software is performing the HTTPS scanning so that I will be able to add its certificates to Firefox and hence, be able to use the Firefox properly?
In my work computer,...which software is performing the HTTPS scanning
This is probably legal SSL interception done by a firewall in your company. If you want to know the exact software used for scanning ask your local network administrator.
... so that I will be able to add its certificates to Firefox and hence, be able to use the Firefox properly?
If you look at what certificates your server sends you have a look at the certificate details in the browser, especially at the chain certificates. But to make sure that what you get is really the companies certificate used for SSL interception and not some malicious man-in-the-middle attack you should verify your finding with your network administrator. And I'm pretty sure that if they do legal SSL interception they also help you do add the certificate to your browser - at least as long you are allowed to install alternative browsers to your computer and/or your own computer to connect to the companies network.
since yesterday afternoon at 1.30pm, two separately written applications that access the SagePay payment gateway and the Reporting API Endpoint have both returned the following error:
The server committed a protocol violation. Section=ResponseStatusLine
This occurs in the code at the point of
System.Net.HttpWebRequest.GetResponse()
The payment application hasn't changed since 2009 and was written by an ex-member of staff and is ironically scheduled to be replaced in 3 weeks. The Reporting application was written at the end of last year and has worked since inception until yesterday.
I have spoken to SagePay and they advise that nothing has happened from their perspective and the only thing on my mind was the recent disabling of SSLv3 last month but at the time, the reporting tool was changed to use TLS and I have checked this today and it is indeed using TLS.
Is anyone able to shed any light on what could be causing this please?
Thank you.
OK - I have a fix for this :)
Having spoken to Sagepay, they no longer support Triple DES encryption, only AES. By default Windows 2003 won't use AES - hence the problem.
However, if you install the fix in this article: https://support.microsoft.com/kb/948963 it will enable AES and fix the problem.
BTW, it seems like the link to the hotfix in that article is broken, but this link works: http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe
It does require a reboot, and you will need to disable all protocols apart from TLS1.0 in order for this to work.
We have the same problem. One suggestion is to add the following to the web.config:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
This at least avoids the protocol violation, but leads to the following error for me instead:
The underlying connection was closed: The connection was closed unexpectedly.
One other point which I would be interested in your comment on, is that we can only reproduce this error on Windows 2003 servers. On Windows 2008 it works OK. I have also reproduced this on my Windows 7 dev machine by forcing it to connect via SSL3.
I have disabled SSL3 in Schannel for both client and server applications, but I am wondering if it is continuing to connect via SSL3 for some reason, rather than using TLS. Any thoughts?
I have just spoken to someone at SagePay about this who says that this is an issue with the connection using SSLv3. We thought we had disabled this in November last year, but he said that when using Windows Server 2003, he’s heard that sometimes it looks like the SSLv3 is being disabled but that when it gets to the last step it doesn’t do it for some reason.
I'm looking into this now with our server hosts, but this could be something for you to look at too.
As part of a ClickOnce deployment I'm running mage.exe
mage.exe -Sign "manifest file" -CertFile Cert.pfx -Password yepit5right -TimeStampUri http://timestamp.verisign.com/scripts/timstamp.dll
the certificate comes from Verisign in the first place so using their timestamping service.
This works fine on some machines but not others, and they come back with the very readable error code of -2147012865 which translates to error 12031 - ERROR_INTERNET_CONNECTION_RESET.
I can connect out through IE on that machine to sites such as stackoverflow.com and so the proxy settings which it needs appear to be correct.
Does mage.exe support authenticating proxies? This used to work, over a year ago now, before we had a major outbound proxy change which I think included changing from non-authenticating to using integrated authentication at the proxy layer.
Thanks
Not a great answer but it turns out that mage.exe cannot authenticate through to a proxy when making the request out to the timestamping service.
To get around this restriction I have added the source machine and the target URL to our outbound proxy's "whitelist" of requests that are allowed out without requiring proxy authentication. As you could imaging doing this within a corporate environment where the security team own that list was not a simple task, I much prefer cracking the technical nut.
As soon as this was added mage.exe started behaving as expected, and as it behaves in our test environments which have a non-authenticating proxy.
Question: How can I securely include the SSL cert required for push notifications in the installer for my server product?
Background: Apple Push Notifications require a client SSL cert to be in place on the server that's making the calls to Apple.
My product has a traditional client/server architecture, i.e. a customer installs the server within their intranet and then obtains the iOS client from the App Store and connects the client to their instance of the server.
The point here is that the customer installs the server themselves, rather than a cloud architecture where I would manage the server myself.
My problem is that I don't know how to package the push notification certificate in the server installer in a secure way. I can't distribute the .p12 file without a password because that would expose my private key, and I can't use a password because the password would have to be included somewhere else in the installer which would defeat the purpose. Do I need to relay messages from all of my customers through a server that I manage, which has the SSL client cert? Do I need to install the SSL cert by hand into every one of my customers' sites?
Surely others must have run into this problem already? Or has everyone moved to the cloud?
Here is a major observation that happened to me over the weekend regarding Apple Push certificates. While there many references out there to setting up the Apple Push server side certificates, here is a MAJOR point I discovered that I cannot find referenced in any Apple documentation, or via google.
My situation: I have Push Certificates (sandbox) working great on Windows Server. Now it is time for production. Installation of production certs is successful like many times before. However, while the production push transmission completes error free, no pushes are generated to the device. Hmmm.
I just HAPPEN to notice that my Mac's time is roughly a minute off from the Windows Server (command-tabbing between MacOS and VM-Ware). Looking at Windows and Mac Settings, I see Windows internet time is set for "time.windows.com", and the mac for "time.apple.com". Just for kicks, I change the windows server time to "time.apple.com". Instantly, pushes are now being sent to the device. Nice. :-)
I dodged a major bullet here, this would have probably driven me insane trying to figure this one out. I do not claim to be an SSL cert guru... I (like most every one) just want to get this stuff to work because we have bigger fishes to fry.
I hope this is useful information.
I know only the solutions to install certificates for push notifications :
.p12, the password is in the code of the sending
.cer (.p12+private key) the password is requested at the importing of the certificate.
In the first case, you can deploy your solution, and download some code, for example xml with the password.
I'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html