Error when VirtualBox checks for Updates => Fixed in SVN

[Lucas J. Carlson]

I have been having this problem since I updated from 4.3.8 to 4.3.10 and 4.3.12. When VirtualBox checks for updates, I get this error: The network operation failed with the following error: Unknown reason. I am a computer tech and have done firewall troubleshooting both in Windows Firewall and on the Router. That's not the issue. I even redownloaded/installed 4.3.8 back onto my system and have the same problem. I have Windows 7 Home Premium 64-bit installed on this laptop (HP Pavilion g7-1139WM Notebook PC) and Windows XP Professional installed on the other laptop (Dell Latitude D600). I couldn't find a VBox.log only the VBoxSRV.log and the selectorwindow.log because I formatted this laptop and haven't installed or ran any guest OS's yet. It's not an urgent thing to fix. I just thought I would let you know as I can still manually check for updates through the browser on your website, but it is nice when the software automatically tells me when there is a new version. I really love the work that you guys put into VirtualBox. I LOVE this software and use it every day especially for games that won't install on a 64-bit system. Keep up the good work.

[Lucas J. Carlson]

A copy of my VBoxSVC.log

[Lucas J. Carlson]

A copy of my selectorwindow.log

[bl184999]

There is a related thread in the forum about this.

​https://forums.virtualbox.org/viewtopic.php?t=61635

[Mihai Hanor]

VirtualBox fails to acquire ​http://www.verisign.com/repository/roots/root-certificates/PCA-3G5.pem
The response it gets is "301 Moved Permanently" and it gets redirected to ​https://www.symantec.com/about/profile/policies/repository.jsp

[Frank Mehnert]

Thanks for the report. The problem will be fixed in the upcoming 4.3.14 release (4.3.14 RC1 is available ​here.

[Frank Mehnert]

Fixed in VBox 4.3.14.

[CyberManifest]

Looks like it's back again in Virtualbox 5.0.0 r101573... I'm experiencing the same problems as mentioned and this is on a MacBook Pro Retina 15" Mac OS X Yosemite 10.10.4 Host.

[Clayton Carney]

Windows 10 Home 64-bit. VBox 5.0.1r102010. Same problem.

Network Operations Manager

Checking for a new VirtualBox version...

The network operation failed with the following error: Unknown reason.

Have tried disabling Windows Firewall and Windows Defender. Same result with Standard User logon. However, with an Administrators Group logon, problems does not occur, even with Firewall and Defender enabled.

[CyberManifest]

Still getting the error after upgrading to Mac OS X Yosemite 10.10.5 Host

[Elijah]

still the same problem when checking for updates

[Frank Mehnert]

Confirmed. Will be fixed in the next maintenance release.

[Frank Mehnert]

Fix is part of VBox 5.0.4.

[gmlevin]

Problem seems to have returned in Version 5.1.14 r112924 (Qt5.6.2). Not mentioned in the change log for 5.1.16.

[easydoor]

I have the same problem. Win 8.1, long time I can not update because of this annoying ssl message. I tried everything above, To delete certificate, to delete file vbox-ssl-cacertificate.crt, to uninstall, VB, the install again, and nothing.

In last let it say 7-8 version I have all the time this problem. Now Im on the latest release 5.2.8

Is there any tutorial how to solve this annoying problem?

[davisum]

On Windows 10 on an IPv6-only network, the File -> Check for updates... returns the following:

The network operation failed with the following error: During network request: Connection refused

I'm guessing that the VirtualBox "check for updates: functionality is only using IPv4 literal addresses and not using DNS or IPv6 API???

All my other applications on this IPv6-only network are working fine and can get to both IPv6 and IPv4 servers because we have a NAT64 translator on our network.

My guess is that all VirtualBox needs to do is use either DNS address lookups or IPv6 API for this functionality?

To work around this I have to turn IPv4 back on for my Windows box, do the update, and then turn it back off.

If this functionality could work correctly on an IPv6-only network then this work-around would not need to be employed.