My machine recently updated to the Windows 10 "Anniversary Update"
Before the upgrade, I installed the latest Covenant Eyes 7.2.0. I had previously tested a prerelease version of this version of Windows, and I had had trouble with access to the internet failing entirely in certain applications.
I think this may be a known issue, but using the current Covenant Eyes the previous issue is resolved -- internet access does work -- but SSL connections all fail due to peer signing being the wrong certificate. This means that my email client prompts multiple times a day to accept an unsafe connection, and it means lots of trouble for using the Windows Store and many developer tools that use SSL signing.
Hoping you guys might have ideas to work around this
Thanks
- 14 Posts
- 1 Reply Like
Posted 3 years ago
Annelise, Official Rep
- 251 Posts
- 13 Reply Likes
I apologize for the difficulties you've been experiencing. I am going to pass along your issue to our developers and hopefully we will be able to offer you resolution soon! Thank you for contacting us and thank you for your patience!
Best regards,
Annelise
Jared Burkeen, Software Engineer
- 23 Posts
- 4 Reply Likes
Thank you for bringing this issue to our attention.
What email client are you using, and what type of email account?
Also, what specific developer tools are giving you trouble?
We'd like to be able to reproduce this issue so we can work on resolving it.
Thanks,
Jared
- 14 Posts
- 1 Reply Like
* When you install and run the Android SDK Manager, it fails to download files from "https://dl.google.com" because of an error, "SSLPeerUnverified peer not authenticated
* Commands such as "sudo apt-get update" or "sudo apt-get upgrade" fail when using the Bash on Ubuntu for Windows shell. Allowing insecure certificate verification fixes that issue
* Compiling an Android using Gradle fails to fetch packages from jcenter and maven due to failing SSL validation, forcing both to HTTP addresses (instead of HTTPS) resolves the issue
* My mail client that "The certificate for imap.gmail.com is signed by the unknown Certificate Authority "CovenantEyesProxy (66232)". It is not possible to verify that this is a valid certificate."
I have been hunting down issues like this, one at a time, forcing different systems to allow insecure connections, but I think it all tracks back to an underlying issue with SSL certificates
Thanks :)
Jared Burkeen, Software Engineer
- 23 Posts
- 4 Reply Likes
I'm not able to reproduce this issue on a Windows 10 64-bit virtual machine.
I installed and ran the Android SDK Manager without any issues downloading files.
I also was able to run the Bash update commands without any errors.
I wonder if the issue arose from upgrading to the Anniversary Update while having Covenant Eyes installed.
Can you uninstall Covenant Eyes, verify that the SSL issue is gone, and the install CE 7.2.0?
Thanks,
Jared
- 14 Posts
- 1 Reply Like
I just uninstalled Covenant Eyes (I had to enter Safe Mode in order to uninstall because the uninstaller kept crashing), restarted, installing Covenant Eyes 7.2.0 again, restarted.
Android SDK is working, mail seems to working without complaint. I still see issues in Bash, but this may be unavoidable.
Here's a simple way to test:
$ wget https://www.google.com
--2016-08-10 11:36:34-- https://www.google.com/
Resolving www.google.com (www.google.com)... 216.58.216.132, 2607:f8b0:400a:808::2004
Connecting to www.google.com (www.google.com)|216.58.216.132|:443... connected.
ERROR: cannot verify www.google.com's certificate, issued by ‘/C=US/CN=CovenantEyesProxy (53855)’:
Unable to locally verify the issuer's authority.
To connect to www.google.com insecurely, use `--no-check-certificate'.
$ wget https://www.google.com --no-check-certificate
--2016-08-10 11:36:42-- https://www.google.com/
Resolving www.google.com (www.google.com)... 216.58.216.132, 2607:f8b0:400a:808::2004
Connecting to www.google.com (www.google.com)|216.58.216.132|:443... connected.
WARNING: cannot verify www.google.com's certificate, issued by ‘/C=US/CN=CovenantEyesProxy (53855)’:
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
[ <=> ] 11,164 --.-K/s in 0.005s
2016-08-10 11:36:45 (2.13 MB/s) - ‘index.html’ saved [11164]
Thanks :)
- 14 Posts
- 1 Reply Like
http://askubuntu.com/questions/73287/...
Is there a certificate installed on my system somewhere I could try and copy?
- 8 Posts
- 0 Reply Likes
- 14 Posts
- 1 Reply Like
- 58 Posts
- 8 Reply Likes

I understand why one might want to monitor SSL traffic, but this is really very problematic. Forcing other applications to accept invalid certificates is really a very bad solution because then then the security that the SSL (well, TLS really) protocols provide are completely circumvented.
- 58 Posts
- 8 Reply Likes
Does Covenant Eyes have a certificate we can import and trust on our local systems to prevent these issues? I'm not worried about CE stealing private data that they shouldn't have, but I am worried that this SSL proxy you have installed introduces a major security vulnerability for your users in addition to breaking a lot of applications that rely on SSL.
- 58 Posts
- 8 Reply Likes

I'm on CE 7.2.4
I took a look at the Trusted Root Certification Authorities store in the cert manager and found these three certs:

Are there any others? Is this an app-specific problem that will have to be solved application by application (I hope not...)?
Shawn Pillsbury, Official Rep
- 51 Posts
- 16 Reply Likes
The Windows team is investigating the issues you reported. I don't have specific answers for you at this point, but we were able to recreate the Office Activation issue. The details you sent have been helpful with the investigation.
We'll keep you posted on our progress.
Thanks,
- 58 Posts
- 8 Reply Likes
Bill Lawson, Employee
- 7 Posts
- 0 Reply Likes
Would you try uninstalling Covenant Eyes and then installing the latest beta (7.2.4) from "My Account?"
aggieben I'm wondering if something might not have been cleanly uninstalled when you upgraded to 7.2.4 and this would test that theory.
Rhys it looks like you are using Covenant Eyes version 7.2.0 and there are some known issues with that version and the Windows 10 Anniversary update.
Please report back here after you have uninstalled the versions you are using now and then installed 7.2.4 and I will see what we can do if this doesn't work for either of you.
Thanks,
Bill
- 58 Posts
- 8 Reply Likes
I thought I had 7.2.4 installed previously - in fact, I never even downloaded 7.2.0 (this is a new workstation build); but whatever the cause, it's better.
- 58 Posts
- 8 Reply Likes

This is during an "apt update" on WSL (aka Ubuntu on Windows).
- 8 Posts
- 0 Reply Likes
- 1 Post
- 0 Reply Likes
- 4 Posts
- 1 Reply Like
I have noticed that Covenant Eyes desktop app adds self-signed SSL certificates to the Windows trusted Root certificate repository.
Recently I have removed two SSL CovenantEyesProxy certificates from the Windows Repository and as a result connections to certain https websites could not be established anymore (SSL error) -
For example - https://www.google.pl
Nonetheless other https sites were still working correctly.
After capturing data with Wireshark I could see that connection was closed by the client host (with FIN tcp packet) upon receiving New Session Ticket, Change Cipher Spec from the google server (before that - client/server hello were exchanged along with google certificate).
After installing removed CovenantEyesProxy certificate to Windows Root cert repository, connection to google worked again and packet capture showed same google certificate in use (signed by Google Certificate Authority).
As far as I remember, there was a time when browser (while navigating through https sites) was reporting certificates received from the server signed by CovenantEyesProxy cert (not by cert autority).
In general SSL proxy allows third party to present self-signed certificates to the clients (during the SSL handshake) and if certificate is signed by authority known to the client (imported to Windows repository), than the client will not be warned of any security risk.
As a result of using SSL proxy - traffic can be decrypted by the third party.
I'm just wondering can you please explain what is the reason of adding CovenantEyesProxy certificate to Windows Root Certificate Authority repository if (according to packet capture) traffic remains encrypted using original's server certificate?
Can You please advice if accounting information from SSL connections to other sites is gathered based on information stored in the HTTP header?
Is the technique you are using allows to decrypt SSL transactions to google sites (only) or also to other sites?
Thanks in advance.
Michal
- 1 Post
- 0 Reply Likes
https://blogs.msdn.microsoft.com/phkelley/2014/01/20/adding-a-corporate-or-self-signed-certificate-a...
- 1 Post
- 0 Reply Likes
Robert B, Official Rep
- 305 Posts
- 21 Reply Likes
While CE does not function with Ubuntu (the low level of demand hasn't merited the investment), I can help you with the apparent conflict with Google Sheets. Please contact our Customer Service Team at 877-479-1119 for directions on getting version 7.3.8. You can also email me at robert.b@covenanteyes.com.
Robert
- 1 Post
- 0 Reply Likes
I just had a similar issue while using Bash for windows 10 being unable to verify SSL certificates on connections. To fix I exported the Covanant eyes certificates from windows
Click Start, Run, then type “mmc” and hit enter.
In the leftmost menu, choose “Add/Remove Snap In”.
Click “Add”, then click “Certificates”, then OK.
Then open Trusted Root Certification Authorities – then Certificates
Once this is done find the certificates that are issued by CovenantEyesProxy
Right click, then all tasks, then export
Then use the DER encoded binary X.509, save in a file you can find in the Ubuntu virtual machine
Next open up the ubuntu virtual machine, and navigate to where the certificates were saved, then run the following command to convert them
openssl x509 -inform DER -in <cert name>.cer -out <cert name>.crt
Next we need to copy these newly created certificates to the place where ubuntu will look for them
sudo cp *.crt /usr/local/share/ca-certificates/
Finally update the certificates
sudo update-ca-certificates
If all has worked then you should be able to run
wget http://google.com without issue
Finally, if you like me are running applications like git or pip, you might need to further override the certificate there as well, since these appications will be looking specifically for the certificate that is issued by that authority.
For instance in pip I simply had to add the certificate flag
pip install --cert /usr/local/share/ca-certificates/<cert name>.crt <package name>Note here I simply tried both certificates, and one worked, it is probably possible to make it so that it automatically checks both, but there were only two to check in my case.
- 58 Posts
- 8 Reply Likes
This time, I can't get to Google Mail:

This is a serious regression.
Robert B, Official Rep
- 305 Posts
- 21 Reply Likes
Try uninstalling 738 and installing 7247. That version is freely available in the Downloads section of your My Account Menu. If you still have a problem getting to Gmail, call the Customer Service team at 877-479-1119.
You were right about 738 being a beta; it had some components that the Developers wanted to try out. They learned a few things from the people that used it, but eventually determined that that version wasn't going to become a full-fledged release. 7247 is the way to go for now.
Again, if you still have an issue accessing Gmail after installing 7247, call us. That will result in the quickest resolution for your situation. Thanks for reaching out!
Robert
- 58 Posts
- 8 Reply Likes
Related Categories
-
Covenant Eyes for Windows
- 530 Conversations
- 155 Followers