Our OpenVPN Connect v2 and v3 client software for macOS is signed using our official digital signature. The signatures of signed installers are also stored on Apple’s servers using their software notarizing solution. Signing and notarizing our software ensures that the program you download from our website or our business products is intact and valid for installation on your system. This is beneficial to the security of our software and your systems.
The digital signature used on our OpenVPN Connect v2 and v3 client software for macOS will expire on October 26, 2020. After this date a particular check on the digital signature might fail. We have updated our client software with a new digital signature that will be valid until September 2025.
Please note that already installed software is not affected by this. That will continue to function normally. It is only new installations that might get a warning message during the installation process about the certificate being invalid because it has expired.
We have updated our client software on our website and on our OpenVPN Cloud product. These versions of OpenVPN Connect have been updated with the new signature:
On OpenVPN Access Server, the administrator of the server will have to update the Bundled Clients Package (openvpn-as-bundled-clients) to v14 or higher to ensure that the newly signed OpenVPN Connect v2 and v3 software installers can be offered to your users on your Access Server.
Instructions to update the bundled clients package on your Access Server are below. If you have any questions, please contact our support team for more information.
To update on Ubuntu/Debian systems:
sudo apt update && apt upgrade openvpn-as-bundled-clients
To update on CentOS/Red Hat systems:
sudo yum update openvpn-as-bundled-clients
On May 30th of 2020, a CA root certificate by COMODO/Sectigo Addtrust expired. After that date, any legacy systems that use this CA root certificate will experience an outage or display an error message like “certificate is expired” or “certificate is invalid” when verifying a certificate signed by COMODO/Sectigo Addtrust.
What can happen in certain cases is that you might have a certificate that is valid, but because the CA root certificate it chains to for verification is expired, you will still get a message saying that the certificate is expired or invalid.
More information on the problem and possible solutions can be found here on the official Sectigo website:
Sectigo has other, older, legacy roots apart from the AddTrust root, and they have generated cross-certificates from one in order to extend backward compatibility. The cross certificate is signed by the root called “AAA Certificate Services”. Customers who have embedded AddTrust External CA Root into their applications or custom legacy devices may need to embed the new USERTrust RSA CA Root replacement.
Older Access Servers can contain CA root information that is outdated. To resolve that, you can update the Access Server to the latest version that contains the most up-to-date information.
If you experience problems with COMODO/Sectigo Addtrust certificates, we recommend that you contact them for support on their certificates.
One of our customers has reported a possible issue to us that leads to LDAP authentication bypass on our Access Server 2.8.0. We investigated this and were able to reproduce the problem. It has been discovered that when using an LDAP authentication system in combination with the Access Server version 2.8.0 (other versions are not affected) that there is a security flaw with the login process. Customers that are using two factor authentication, which many fortunately do, are still protected thanks to the extra security factor. Regardless, we recommend that people that are running Access Server 2.8.0 in combination with LDAP to upgrade to version 2.8.1 immediately.
Customers that are using Access Server without LDAP are not affected by this issue. Customers using a version of Access Server other than 2.8.0 are also not affected.
If you are running Access Server 2.8.0 and you use LDAP authentication, you should update to 2.8.1 as soon as possible. We released this version within hours after we were able to reproduce this problem. We are also submitting a CVE report for full transparency and to make people aware that they should update. The CVE we published for this is here: CVE-2020-9853.
A research team from the University of New Mexico discovered a vulnerability currently being tracked as CVE-2019-14899 which claims that VPN connections can be hijacked on Linux and Unix systems. The report mentioned the OpenVPN protocol. As part of good security principles, we are looking into this and any possible attack vectors, however we have found no flaws in the OpenVPN software.
An initial investigation by our security experts, and experts across the globe, reveals that this issue affects all network interfaces, not VPN in particular.
“It doesn’t appear to be a flaw in the OpenVPN software, but a flaw in the configuration of the operating system itself. The issue is more in how the operating system deals with this type of attack in general, rather than anything going wrong in the VPN connection itself,” says OpenVPN Access Server Product Manager, Johan Draaisma.
To our knowledge, the vulnerability is only impacting Linux and Unix systems and requires that the attacker has control over your Internet access point and can therefore reach and affect your computer outside of the VPN, in the local network, for example. Based on this, the attack is somewhat limited, and there is no straight-forward way to retrieve unencrypted data from the VPN connection.
“The issue may actually be located in the Linux operating system settings rather than in our software, but given the serious nature of the attack, we are paying close attention and will consider whatever steps are appropriate to ensure OpenVPN remains safe to use on these affected platforms. For now enabling the ‘reverse path filter’ setting in the OS is a good first step to help protect against this attack,” says Draaisma.
OpenVPN Inc. is keeping a close eye on the discussions currently ongoing, and possible solutions. Currently there is no evidence suggesting there is a flaw in the OpenVPN software itself.
The licensing system of the OpenVPN Access Server product has been updated to add support for new features and to enhance security. Because of this there have been some changes on our end, and this requires a small change to be implemented on your existing OpenVPN Access Server installation as well. The impact of this is kept as minimal as possible, and we provide information below to answer the most common questions and to make this transition go as smoothly as possible. The change to the licensing system has happened on January 20th of 2019 so it is important you take action. Please review the information below to learn what impact this has, and how to take the necessary steps.
Please note that this change does not affect our Amazon AWS tiered instances that are pre-licensed with a predefined amount of connections. These are billed through Amazon AWS directly and use a different licensing system that does not need this update.
You should upgrade your Access Server to the latest version available on our software packages page, which includes the changes to the licensing system. Alternatively, if you do not wish to upgrade now, you may use our licensing patch to update only the licensing code on an existing Access Server. The patch is designed so it can be applied live without shutting down or cold restarting the Access Server service, so VPN clients don’t need to be disconnected, and it is compatible with Access Server 1.8.3 and above.
We are making it possible for new options for licensing in the future, in other words to create a more flexible licensing system. This will make it easier for you to change the amount of connections on an Access Server in a future update of our licensing system, and will allow us to prepare better licensing options for the exciting new clustering feature that we are developing (only available as beta at this time). On top of that we are improving the security of the licensing system while we are at it. This requires that Access Server is updated as well.
Actually very little. If you continue using your current OpenVPN Access Server as it is without either upgrading or applying the licensing patch, it will function normally and the license keys that are on it right now will continue working just fine, even after January 20th (assuming your license keys do not expire before then of course). However, when you try to activate new license keys on an old or unpatched Access Server after that date, or renew license keys for this server and try to activate a renewal key on the server, it will produce an error message. To resolve this, either upgrade your Access Server to the latest version, or apply the live licensing patch. You can then activate license keys again normally after that date.
No. Those are completely unaffected and will continue to function normally.
No. Your license keys remain completely unchanged.
Yes, please do. You may upgrade your Access Server at any time before or after January 20th. If you do it before that time, you will not have to worry about any possible licensing problems.
That’s alright, we understand that our product is being used in highly critical situations and updates and restarts can be disruptive. So we’ve accounted for that. First of all, if you do nothing, your existing license keys will continue working fine even after January 20th (assuming your license keys do not expire before then of course). And if after January 20th you want to activate a new license key, simply use our live licensing patch. With this patch you can continue using and running your current Access Server version. It will not require your Access Server service to go down and disconnect your VPN clients, but it simply patches the licensing system in memory while Access Server is running. If you have concerns, you may consider setting up a test platform and test the live licensing patch on that to ensure there will be no problems on your production system.
Unfortunately the new licensing system cannot function properly on an Access Server that old. Version 1.8.3 is already more than 8 years old. Aside from the security considerations of running severely outdated software, we also just do not support such an old version anymore. We recommend that you upgrade to the latest version. However, if for whatever reason you must continue running such old software, and wish to activate a license key on this, contact our support ticket system and let us know the license key you wish to activate, and we will help you perform an activation procedure for your Access Server.
In beginning of November of 2017, we released a new version of OpenVPN Connect for Android with many security and functionality improvements. Shortly thereafter we received reports from some users that making a connection was no longer possible. The error messages varied from “certificate verification failed” to “TCP EOF” network errors. We’ve traced this down to certificates being used by older implementations of OpenVPN open source servers that were using MD5 type signature hashes. These signatures are insecure and should not be used anymore.
It is important to note here that OpenVPN Access Server was not affected by this issue. We are talking here about open source implementations of OpenVPN that were using certificates signed with a hashing method called MD5 that has been determined to be broken and which should not be used anymore. Customers of our commercial OpenVPN Access Server offering did not suffer from these problems and do not need to take action. This only really affects people using an open source OpenVPN implementation either set up themselves or part of a third-party embedded product like a router or VPN server product.
We have temporarily added support for MD5 type signature hashes back into the OpenVPN Connect for Android app, which is available on the play store now. If you upgrade to this version then this particular problem should be resolved for you. But the real problem, namely the use of MD5 hash certificates, is not resolved by this. It is strongly encouraged to use secure certificates instead of the flawed MD5 type certificates. It is absolutely not secure to use these older type of certificates and we cannot in good conscience continue to support such a poor level of security in our OpenVPN security product. Therefore support for MD5 will be ending in May of 2018. This gives our users time to migrate to a secure configuration using for example certificates signed with SHA256 type hash or better.
See FAQ item regarding MD5 support on Android app for more technical details on how to detect and resolve this problem.
Security researcher Ahamed Nafeez has presented a new attack vector which targets VPN tunnels which utilize compression, named VORACLE. The attack vector bears similarities to the CRIME and BREACH attacks, which hit especially HTTPS based connections.
It has been discovered that it is possible to gain information about an encrypted VPN tunnel’s contents in very specific circumstances, if an attacker has the ability to capture the encrypted data packets while a certain type of data is transferred through the VPN tunnel. By that we mean that if a VPN user visits for example an unencrypted HTTP website through an encrypted VPN tunnel, and this information is being compressed and encrypted through the VPN tunnel, certain clues about the contents of this information can still be gathered if the encrypted packets can be captured and analysed, and data can be fed through the VPN tunnel by the attacker. To explain this better, following below is a simplified example. The example mentioned here is not the only possible attack against encryption combined with compression, and it is also very simplified, but it is useful to explain the principle behind attacks like VORACLE, CRIME and BEAST.
Let’s say Alice has setup a login page. To check passwords entered there, Alice sends a message like “tell me if <the password entered> matches <secret password>” to Bob. This information between Alice and Bob is sent through an encrypted VPN tunnel that also uses compression. The more similar the <the password entered> is to <secret password> the better this message compresses. If the attacker Eve can ask Alice to verify passwords and can see the length of the encrypted VPN messages, she gets a pretty good idea how close her guesses are, since the encrypted messages get shorter when her guesses get better.
Without compression the length of the encrypted packets does not change, so Eve cannot gain any information from this. Strictly speaking the length changes if Eve’s password length changes but that gives no additional information. The real world attacks are more complicated and need to take in account the specific circumstances (for example HTTPS or VPN) but they rely on the same principle as demonstrated in this simple example.
Due to the fact that exploiting such an attack is not trivial, we are not treating this situation as an emergency. For now, it is advised that users of the OpenVPN Access Server and the OpenVPN Connect Client software disable the use of compression. This effectively makes exploiting this vulnerability impossible. This can very easily be done on the OpenVPN Access Server by going to the admin web interface, and going to Advanced VPN. There you can disable compression. The client connection profiles may still provide an instruction to enable compression, but it will be disabled if the server denies the use of compression.
For open source OpenVPN users, we direct you to the community wiki article regarding VORACLE.
There are still discussions ongoing on how exactly in the open source OpenVPN project compression will be disabled, but for now in our commercial products we will be disabling compression by default in future releases of Access Server. We intend to make it so that when people update their OpenVPN Access Server, or install a fresh Access Server installation, the default setting will be that compression will be disabled. We will also be hiding and disabling the compression feature in later releases of OpenVPN Access Server and work on phasing it out entirely over time, as there is at this time simply no secure method of guaranteeing the security of the data in all situations while compression is enabled.
Our Private Tunnel cloud service had compression switched off already, so is not affected by this issue.
If you wish to disable compression on your own Access Server, go to the admin web interface, go to Advanced VPN, and switch off support for compression.
For a short while now it’s been known that there are some serious flaws called Meltdown and Spectre that are causing possible security problems for almost all computers. A solution for this, or at least most of the problems, has been created in the form of kernel patches and adjustments in the deepest levels of operating systems like Windows, Macintosh, and Linux, and so on. OpenVPN Access Server itself is only a user-space program and does not run in the kernel and therefore we as creators of the Access Server product do not create these patches. However, we can inform our users on how to get the necessary patches.
Our OpenVPN Access Server appliances have for roughly the past 3 years been based on Ubuntu 13, Ubuntu 14 LTS, and Ubuntu 16 LTS. It is important to figure out which operating system your Access Server runs on, and to then take appropriate action to update the operating system software to get the patches and to verify that they have been installed. For Ubuntu specifically there is a page that describes very well how to patch Ubuntu:
For users that run another operating system or an operating system that is no longer supported and updated by their maintainers, it is recommended to plan maintenance to set up a new installation and to migrate data and activation keys (if applicable) to the new server setup, so that you can then enjoy updates for the operating system and get the necessary patches to mitigate the most problematic issues of Meltdown and Spectre. An alternative option is to perform an in-place dist-upgrade of the operating system, but success in this may vary and there is a chance the activation keys may be invalidated in the process, requiring intervention from us to reissue your activation keys for you. The safest course of action when your operating system is no longer supported is to set up a new system with a supported OS and contact us to get activation keys migrated to the new system once things are setup and tested properly.
More information on the Spectre and Meltdown issues can be found here:
More information about a migration process and how to update Access Server itself is here:
In beginning of November of 2017, we had released a new version of OpenVPN Connect for Android with many security and functionality improvements. Shortly thereafter however we received reports from some users that making a connection was no longer possible. The error messages varied from “certificate verification failed” to “TCP EOF” network errors. We’ve traced this down to certificates being used by older implementations of OpenVPN open source servers that were using MD5 type signature hashes. These signatures are insecure and should not be used anymore.
It is important to note here that OpenVPN Access Server was not affected by this issue. We are talking here about open source implementations of OpenVPN that were using certificates signed with a hashing method called MD5 that has been determined to be broken and which should not be used anymore. Customers of our commercial OpenVPN Access Server offering did not suffer from these problems as we never used such a weak cipher and do not need to take action. This only really affects people using an open source OpenVPN implementation either set up themselves or part of a third-party embedded product like a router or VPN server product with some poor security settings.
We had temporarily added support for MD5 type signature hashes back into the OpenVPN Connect for Android app, which is available on the play store now. If you upgrade to this version then this particular problem should be resolved for you if you go into the setting and enable support for weak ciphers. Eventually though, support for this will disappear entirely. But the real problem, namely the use of MD5 hash certificates, is not resolved by this. It is strongly encouraged to use secure certificates instead of the flawed MD5 type certificates. It is absolutely not secure to use these older type of certificates and we cannot in good conscience continue to support such a poor level of security in our OpenVPN security product. Therefore official support for MD5 will be ending in May of 2018, and we may allow this some time more through the use of a special override in the settings of the client program. This gives our users time and motivation to migrate to a secure configuration using for example certificates signed with SHA256 type hash or better.
See FAQ item regarding MD5 support on Android app for more technical details on how to detect and resolve this problem.
A while ago an issue was discovered in the Network Time Protocol (NTP) daemon that we generally advise people to install on a server running OpenVPN Access Server on Ubuntu. The purpose of the package is to ensure that the time is always correct on the server. This is especially vital when you make use of the Google Authenticator functionality built into the Access Server, as it is time-dependent. On cloud based platforms and other virtualization systems it is not uncommon that time slowly drifts. NTP corrects this automatically.
The vulnerability found has been given designation CVE-2016-9310 and to put it simply, it allows an attacker to use the NTP server to attack other servers with bandwidth. The method is called traffic magnification and basically comes down to make a small request that results in a larger response to a specific target. Enough of these attacks could bring a server down (DoS). Other serious issues have also been found. You can read more about it in the pages linked to below. Fortunately for our users of the OpenVPN Access Server on AWS, our default security groups settings that come with the appliance do not provide access to the NTP daemon at all. So unless these were changed and access was granted to the NTP service port, this flaw cannot be exploited remotely with our Amazon AWS instances.
Ubuntu has created their own page regarding this issue and they have issued fixes for the NTP package. Ordinary apt-get update and apt-get upgrade commands should update your packages to the latest versions that contain fixes for this particular issue. We recommend that everyone makes sure their system is regularly updated to ensure these security fixes arrive on your systems as well.
Minor security vulnerabilities revealed by an audit of OpenVPN, an open source security software providing a safer and more secure internet to millions worldwide, have been fixed. The Open Source Technology Improvement Fund, known as OSTIF, provided funding for the comprehensive security audit. OpenVPN 2.4.0 was audited for security vulnerabilities independently by QuarksLab and Cryptography Engineering between December 2016 and April 2017. The primary findings were two remote denial-of-service vulnerabilities. The issues discovered were minor in terms of security.
The denial of service vulnerabilities found have been fixed in OpenVPN 2.4.2 and 2.3.15 released on May 11, 2017. Likewise OpenVPN Access Server, the commercial version, has also been updated to fix those of the vulnerabilities that were found to be present in the OpenVPN Access Server code as well. OpenVPN Access Server version 2.1.6 and above address the issues found completely.
Google security researcher Tavis Ormandy recently found a bug in the Cloudflare service. You can read more about this on a recent blogpost by Cloudflare. The openvpn.net and privatetunnel.com website both sit behind Cloudflare, a popular content distribution network, for enhanced speed and security. After carefully reviewing the data we feel confident that information was not compromised on our web properties, since the features that are claimed to have been affected were not currently or previously enabled for either of our websites.
That aside and in case we missed something, it is always a good idea to change passwords when something like this occurs and it is never a bad practice to change passwords on a recurring basis. In other words, we recommend you change your passwords as a precaution. We do not store any Credit Card information or sensitive user information on either of our web properties, so even if there was in fact a leak, all they would get are passwords.
There were many other websites that you probably visit that sit behind Cloudflare, so we encourage you to please take a look at this list to see if there was a chance any other sites you have accounts on were possibly compromised. If so we advise you replace your passwords there as well just to be safe.
On April 7th of 2014 we were informed of the vulnerability dubbed Heartbleed (CVE-2014-0160), within one of the Internet’s most significant security libraries (OpenSSL). A great number of services across the internet that use this library, including OpenVPN Access Server, may have been affected by this issue. Since learning of this issue, we have taken immediate necessary steps to ensure the security of OpenVPN and the OpenVPN Access Server product. Within 24 hours we have therefore released patches for specific versions of the Access Server that are affected, and we have released Access Server 2.0.6 with the fix for this issue already incorporated. If you are using an older version that contains the affected OpenSSL library you are advised to update immediately.
The affected versions of Access Server that contain the vulnerable OpenSSL library and are vulnerable to Heartbleed are:
The attack vector that is present on the Access Server with the vulnerable OpenSSL libraries is not present on the Connect Clients, so the risk on the client side is negligible. Only the server that your client connects to could possibly exploit this vulnerability, and even then it is unlikely because we use Perfect Forward Security and TLS-auth on top of the SSL connection which prevents this exploit from being successful. The security of the data channel itself is not particularly at risk, only the web services on the server themselves are. And even then, since we use a privilege separation model, the web services run in a completely different process than the OpenVPN daemons handling the data connections, and therefore the private keys for your OpenVPN connections are not likely to be at any risk. Even so, we did not take chances and have released a fix in OpenVPN Access Server 2.0.7 and newer versions, which incorporate updated clients as well. So update your clients as well.
If you have a version other than the aforementioned versions, you are not vulnerable to the Heartbleed vulnerability, but of course we always recommend to keep your system up-to-date. If you are running one of the mentioned versions, we recommend that you upgrade to the latest version available from our website immediately.
The OpenVPN Connect Client for Windows and macOS should also be updated, and you can do so by updating your OpenVPN Access Server first, and then downloading a new and updated copy of the OpenVPN Connect Client from your updated Access Server.
Note that mobile clients like on iPad, iPhone and Android devices, are not affected as they use PolarSSL instead, so no action needs to be taken there.
The OpenVPN Desktop Client is not receiving maintenance anymore, and has been deprecated for a while. All OpenVPN Access Server customers still using the OpenVPN Desktop Client for Windows should upgrade immediately to the OpenVPN Connect Client that comes bundled with our latest OpenVPN Access Server product. The OpenVPN Desktop Client is obsolete and is no longer maintained or available for download. This client contains a CSRF (Cross Site Request Forgery) vulnerability that can allow remote code execution by a malicious web site, as Stefan Viehböck, SEC Consult, has discovered. The OpenVPN Desktop Client also contains an older version of OpenSSL that has not received recent OpenSSL security updates. This advisory only applies to the OpenVPN Desktop Client app for Windows, and does not affect OpenVPN Connect Client, Private Tunnel, or OpenVPN open source builds for Windows.
We still see some users with this program actively in use. We strongly advise these users to switch to the newer client program titled OpenVPN Connect Client or an up-to-date OpenVPN open source alternative. We advise that you always try to use the latest version of the server and client software where possible.