FAILED TO ENABLE VIRTUAL ADAPTOR –

HOW TO FIX IT

The Cisco VPN client is one of the most popular Cisco tools used by administrators, engineers and end-users to connect to their remote networks and access resources.

With the introduction of Windows 8, Cisco VPN users are faced with a problem – the Cisco VPN software installs correctly but fails to connect to any remote VPN network.

When trying to connect to a VPN network through a Windows 8 operating system (32 or 64 bit), the Cisco VPN client will fail to connect. As soon as the user double-clicks on the selected Connection Entry, the VPN client will begin its negotiation and request the username and password.

As soon as the credentials are provided, the VPN client shows the well-known “Securing communications channel” at the bottom of the windows application:

After a couple of seconds the Cisco VPN client will timeout, fail and eventually the connection is terminated. The user is then greeted by a pop up window explaining that the VPN failed with a Reason 442: Failed to enable Virtual Adaptor error:

INTRODUCING THE FIX – WORKAROUND

Thankfully the fix to this problem is simple and can be performed even by users with somewhat limited experience.

Here are 4 easy-to-follow steps to the solution:

1. Open your Windows Registry Editor by typing regedit in the Run prompt.

2. Browse to the Registry Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CVirtA

3. From the window on the right, select and right-click on DisplayName and choose Modify from the menu. Alternatively, double-click onDisplayName:

4. For Windows 8 32bit (x86) operating systems, change the value data from @oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter to Cisco Systems VPN Adapter.

For Windows 8 64bit (x64) operating systems, change the value data from @oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter for 64-bit Windows to Cisco Systems VPN Adapter for 64-bit Windows (shown below):

When done editing the Value data, click on OK and close the Registry Editor.

You can now run the Cisco VPN Client and connect to your VPN network.  Changes performed do not require a system restart.

Have questions?

Get help from IT Experts/Microsofts Cloud Solutions Partner
Call us at: 856-745-9990 or visit: https://southjerseytechies.net/

South Jersey Techies, LLC is a full Managed Web and Technology Services Company providing IT Services, Website Design Services, Server Support, Network Consulting, Internet Phones, Cloud Solutions Provider and much more. Contact for More Information.

To read this article in its entirety click here.

Following a recommendation by the National Institute of Standards and Technology (NIST), Microsoft will block Windows from accepting SSL certificates encrypted with the Secure Hash Algorithm-1 (SHA-1) algorithm after 2016. Given the number of mission-critical SSL certificates that are allowed to expire from inattention, administrators have their work cut out for them. By knowing what will happen, why it’s happening, and what you need to do, you won’t be surprised by these important policy changes.

What’s Happening?

On November 12, 2013, Microsoft announced that it’s deprecating the use of the SHA-1 algorithm in SSL and code signing certificates. The Windows PKI blog post “SHA1 Deprecation Policy” states that Windows will stop accepting SHA-1 end-entity certificates by January 1, 2017, and will stop accepting SHA-1 code signing certificates without timestamps after January 1, 2016. This policy officially applies to Windows Vista and later, and Windows Server 2008 and later, but it will also affect Windows XP and Windows Server 2003.

SHA-1 is currently the most widely used digest algorithm. In total, more than 98 percent of all SSL certificates in use on the Web are still using the SHA-1 algorithm and more than 92 percent of the certificates issued in the past year were issued using SHA-1.

Website operators should be aware that Google Chrome has started warning end users when they connect to a secure website using SSL certificates encrypted with the SHA-1 algorithm. Beginning in November 2014 with Chrome 39, end users will see visual indicators in the HTTP Secure (HTTPS) address bar when the site to which they’re connecting doesn’t meet the SHA-2 requirement. Figure 1 shows those indicators.

Google is doing this to raise end users’ awareness and to help guide other members of the Internet community to replace their SHA-1 certificates with SHA-2 certificates.

Why Is Microsoft Deprecating SHA-1?

SHA-1 has been in use among Certificate Authorities (CAs) since the U.S. National Security Agency (NSA) and NIST first published the specification in 1995. In January 2011, NIST released Special Publication 800-131A, “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.” This publication noted that SHA-1 shouldn’t be trusted past January 2016 because of the increasing practicality that a well-funded attacker or government could find a SHA-1 hash collision, allowing them to impersonate any SSL website.

Realizing that it’s highly unlikely that CAs and the industry at large will adopt more powerful encryption algorithms on their own, Microsoft is leading the charge by making Windows reject certificates using SHA-1 after January 1, 2017. Doing this will lead website operators to upgrade to stronger SHA-2 certificates for the betterment of all Windows users and the broader public key infrastructure (PKI) community. The Windows PKI blog post “SHA1 Deprecation Policy” noted that, “The quicker we can make such a transition, the fewer SHA-1 certificates there will be when collisions attacks occur and the sooner we can disable SHA1 certificates.”

In the end, the issue isn’t if SHA-1 encryption will be cracked but rather when it will be cracked.

What Do I Need to Do?

January 1, 2017, might seem like a long way away, but now is the time to understand the problem and how to mitigate it.

As per Microsoft’s SHA-1 deprecation policy, Windows users don’t need to do anything in response to this new technical requirement. XP Service Pack 3 (SP3) and later versions support SHA-2 SSL certificates. Server 2003 SP2 and later versions add SHA-2 functionality to SSL certificates by applying hotfixes (KB968730 and KB938397).

Web administrators must request new certificates to replace SHA-1 SSL and code-signing certificates that expire after January 1, 2017. As of this writing, that would probably affect only public SHA-1 certificates that were purchased with a long expiration date (three years or more) or long-duration certificates issued by internal SHA-1 CAs. Most third-party CAs will rekey their certificates for free, so you simply need to contact the CA to request a rekeyed certificate that uses the SHA-2 algorithm.

When ordering new SSL certificates, you should confirm with the CA that they’re being issued with the SHA-2 algorithm. New certificates with expiration dates after January 1, 2017, can only use SHA-2. Code-signing certificates with expiration dates after December 31, 2015, must also use SHA-2.

Note that the algorithm used in SHA-2 certificates is actually encoded to use SHA-256, SHA-384, or SHA-512. All of these are SHA-2 algorithms; the SHA number (e.g., 256) specifies the number of bits in the hash. The larger the hash, the more secure the certificate but possibly with less compatibility.

It’s important that the certificate chain be encrypted with SHA-2 certificates. (A certificate chain consists of all the certificates needed to certify the end certificate.) This means that any intermediate certificates must also use SHA-2 after January 1, 2017. Typically, your CA will provide the intermediate and root CA certificates when they provide the SHA-2 certificate. Sometimes they provide a link for you to download the certificate chain. It’s important that you update this chain with SHA-2 certificates. Otherwise, Windows might not trust your new SHA-2 certificate.

Root certificates are a different story. These can actually be SHA-1 certificates because Windows implicitly trusts these certificates since the OS trusts the root certificate public key directly. A root certificate is self-signed and isn’t signed by another entity that has been given authority.

For the same reason, any self-signed certificate can use the SHA-1 algorithm. For example, Microsoft Exchange Server generates self-signed SHA-1 certificates during installation. These certificates are exempt from the new SHA-2 policy since they aren’t chained to a CA. I expect, however, that future releases of Exchange will use SHA-2 in self-signed certificates.

What About My Enterprise CAs?

If your organization has its own internal CA PKI, you’ll want to ensure that it’s generating SHA-2 certificates. How this is done depends on whether the CA is running Windows Server 2008 R2 or later and if your CA has subordinate CAs.

If you have a Server 2008 R2 or later single-root CA without subordinates, you should update the CA to use SHA-2. Doing so will ensure that subsequent certificates generated will use the SHA-2 algorithm. To check which hash algorithm is being used, you can right-click the CA and go to the General tab. If SHA-1 is listed, you can run the following certutil command to configure the CA to use the SHA-256 algorithm:

You must restart the CertSvc service to apply the change. Now when you view the CA properties, you’ll see that the hash algorithm is SHA-256. All future certificates issued by this CA will use SHA-256, but keep in mind that existing certificates will still be using SHA-1. You need to renew any SHA-1 certificates issued by this CA to upgrade them to SHA-2 certificates.

If your CA is older than Server 2008 R2, you can’t upgrade the CA to use SHA-2. You’ll need to rebuild it with a newer version.

If your organization’s internal CA is multi-tiered with one or more subordinate CAs, you’ll need to reconfigure them to use SHA-2. This is done using the same certutil command just given on each subordinate or issuing CA. Keep in mind that if you use subordinate CAs, you’re not required to update the root CA to SHA-2 since that certificate is at the top of the certificate chain, but it won’t cause any problems if you do. You still need to renew any SHA-1 certificates issued by the subordinate CAs to upgrade them to SHA-2 certificates.

Take Action Now

Administrators and website operators should identify all the SSL certificates used in their organizations and take action, as follows:

• SHA-1 SSL certificates expiring before January 1, 2017, will need to be replaced with a SHA-2 equivalent certificate.
• SHA-1 SSL certificates expiring after January 1, 2017, should be replaced with a SHA-2 certificate at the earliest convenience.
• Any SHA-2 certificate chained to an SHA-1 intermediate certificate should be replaced with another one chained to an SHA-2 intermediate certificate.

The following tools and websites are useful for testing and for further information about SHA-1 remediation:

• Microsoft Security Advisory 2880823. This website discusses the deprecation policy for the SHA-1 hashing algorithm for the Microsoft Root Certificate Program.
• Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP). The section “How to migrate a CA from a CSP to a KSP and optionally, from SHA-1 to SHA-2” in this TechNet web page provides detailed instructions for upgrading a CA to use SHA-2.
• “Gradually sunsetting SHA-1.” This Google Online Security Blog post explains how the transition to SHA-2 affects Chrome and details Google’s rollout schedule.
• SHA-256 Compatibility. This GlobalSign web page lists OS, browser, server, and signing support for SHA-256 certificates.
• DigiCert SHA-1 Sunset Tool. This free web application tests public websites for SHA-1 certificates that expire after January 1, 2016.
• DigiCert Certificate Inspector. This tool discovers and analyzes all certificates in an enterprise. It’s free, even if you don’t have a DigiCert account.
• Qualys SSL Labs’ SSL Server Test. This free online service analyzes the configuration of any SSL web server on the public Internet.

This is your chance to stock up on everything you need.  Save 15% on new web products. Offer expires November 30, 2014 at midnight (Mountain Time).

Please Visit BigBeagle.com.

Depending on how your Windows servers are configured, you may need to disable SSL v3.

Note that older versions of Internet Explorer may not have the TLS protocol enabled by default. If you disable SSL versions 2.0 and 3.0, the older versions of Internet Explorer will need to enable the TLS protocol before they can connect to your site.

For a Simpler Way to Disable the SSL v3 Protocol:

DigiCert is not responsible for any complications or problems if you decide to use this .zip file to disable the SSL v3 protocol on your server.

1. Log into your server as a user with Administrator privileges.
2. Download DisableSSL3.zip, extract the .zip file contents, and then double-click DisableSSL3.reg.
3. In the Registry Editor caution window, click Yes.
4. Restart server.

If you prefer to do it yourself, follow the steps in the instruction below.

Microsoft IIS: How to Disable the SSL v3 Protocol

1. Open the Registry Editor and run it as administrator.For example, in Windows 2012:
   1. On the Start screen type regedit.exe.
   2. Right-click on regedit.exe and click Run as administrator.
2. In the Registry Editor window, go to:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\
3. In the navigation tree, right-click on Protocols, and in the pop-up menu, click New > Key.
4. Name the key, SSL 3.0.
5. In the navigation tree, right-click on the new SSL 3.0 key that you just created, and in the pop-up menu, click New > Key.
6. Name the key, Client.
7. In the navigation tree, right-click on the new SSL 3.0 key again, and in the pop-up menu, click New > Key.
8. Name the key, Server.
9. In the navigation tree, under SSL 3.0, right-click on Client, and in the pop-up menu, click New > DWORD (32-bit) Value.
10. Name the value DisabledByDefault.
11. In the navigation tree, under SSL 3.0, select Client and then, in the right pane, double-click the DisabledByDefault DWORD value.
12. In the Edit DWORD (32-bit) Value window, in the Value Data box change the value to 1 and then, click OK.
13. In the navigation tree, under SSL 3.0, right-click on Server, and in the pop-up menu, click New > DWORD (32-bit) Value.
14. Name the value Enabled.
15. In the navigation tree, under SSL 3.0, select Server and then, in the right pane, double-click the Enabled DWORD value.
16. In the Edit DWORD (32-bit) Value window, in the Value Data box leave the value at 0 and then, click OK.
17. Restart your Windows server.You have successfully disabled the SSL v3 protocol.

For instructions about disabling browser support for the SSL v3 protocol, see Disabling Browser Support for the SSL 3.0.

Due to a critical security vulnerability with SSL 3.0  (an 18-year-old, outdated technology), we recommend disabling it on your server. We have instructions on how to do that in the Updating section but recommend reading the entire document to understand the scope of what this does.

What does POODLE do?
In short, it’s a way attackers can compromise SSL certificates if they’re on the same network as the target if (and only if) the server the target is communicating with supports SSL 3.0.

Google has a lot more detail on their security blog here.

Does POODLE affect my server/sites?
Because POODLE is a vulnerability in SSL technology, it only impacts sites using SSL certificates. If your server or your sites don’t use an SSL certificate, you don’t need to update your server. However, we recommend doing it now in case you do end up installing an SSL certificate at a later date.

Updating
How you update your server depends on whether your server uses a Linux® distribution or Windows® and if it uses cPanel.

cPanel

cPanel requires slightly different steps from any other control panel/operating system configuration.

To Configure cPanel to Prevent POODLE Vulnerability on HTTP

1. Log in to your cPanel (more info).
2. In the Service Configuration section, click Apache Configuration.
3. Click Include Editor.
4. In the Pre Main Include section, from the Select an Apache Version menu, select All Versions.
5. In the field that displays, type the following, depending on which version of CentOS you’re using:

If you encounter errors while applying this update, please review this forum post at cPanel that discusses potential fixes.

6. Click Update.

Preventing POODLE on Other Protocols (FTP, etc.)

Right now, only servers using RHEL can protect themselves against POODLE on non-HTTPS protocols. They can do this by updating the latest version of OpenSSL, and then implementing TLS_FALLBACK_SCSV.

Servers using CentOS do not yet have a known fix for the vulnerability on non-HTTPS protocols. However, we will update this article with those instructions as soon as we do.

Linux (Apache)

Modify your Apache configuration to include the following line:

SSLProtocol All -SSLv2 -SSLv3

For more information on how to do that, view Apache’s documentation.

Windows (IIS)

Modify your server’s registry (which removes access SSL 3.0 support from IIS) using Microsoft’s document here. You can jump down to the Disable SSL 3.0 in Windows section.

SSL Certificate Industry Change

There’s a pretty big change coming for SSL Certificates. And, we think it’s really important to keep you in the loop on these changes.

The biggest change you need to be aware of: if you have an active SSL certificate with an intranet name (e.g.’server1?, ‘mail’, ‘www’, ‘server2.local’, etc.), or a reserved IP address, it’s going to be revoked by October 1, 2016.

Also, on July 1, 2012, customers will no longer be able to purchase, renew, rekey, or manage their SSLs with intranet names or IP addresses that expire past November 1, 2015.

This is an industry-wide decision, not one specific to our company.

For more information on the Certification Authorities Browser Forum guidelines, go here.

For more information on which IPv4 Addresses are reserved, go here. We do not support any certificates using IPv6.

Our highly trained, courteous support staff is waiting to take your call. Whatever time it takes to assist you, that’s the time you’ll receive. We’ll resolve any issue to your complete satisfaction.

Call (888) 505-1532 to get started now

See the difference for yourself!

Fast, affordable and easy-to-use, 4th Generation Hosting is advanced without being complicated, making it the perfect choice for everyone.

Description:

• Hosted across multiple servers with proprietary Dynamic Traffic Management. Easy-to-manage and affordable. It’s the next generation of Web Hosting.

Our highly trained, courteous support staff is waiting to take your call. Whatever time it takes to assist you, that’s the time you’ll receive. We’ll resolve any issue to your complete satisfaction.

Call (888) 505-1532 to get started

GoDaddy, probably the world’s largest domain registrar was sold in 2011 for $2.25 billion dollars. This is a hell of a deal. I can not believe that an Internet company would cost that much. Internet is an intangible business and it is really hard to believe that anyone dot-com based company could cost billions.

Does GoDaddy Worth That Much?

It definitely does! It was reported that the company has a portfolio of 48 million domains and 9.3 million customers worldwide. 73% of those domain names are .com TLDs. GoDaddy nets about $2.95 from each .com registration. The average price of the .com domain registered with GoDaddy is $11.99 per year. Some TLD’s like .net and .org cost $14.99 while most of the other popular web addresses are priced between $12.99 and $19.99 per year. If we calculate the annual revenue the company makes form domain registration, it accounts at more than $500 million per year. However GoDaddy is not just a domain registrar. The company sells Shared Hosting services, VPS, dedicated servers as well as email hosting. Among other web services and products in the company’s portfolio are SSL certificates, DNS, Web design and website analeptics as well as SEO services. The Arizona based company has been cash-flow positive since 2001. That year it had $4.3 million in revenue. In 2004 GoDaddy’s revenue rose to $73 million. The next year – 2005 – the company lost $13.8 million on revenues of $139 million, according to its SEC (http://www.sec.gov/) filing. GoDaddy’s spending on marketing has exploded from $1.2 million in 2003 to more that$15 millions in 2005. The company planned to go public in 2005 and planed to raise $200 million through an IPO. However it has in 2006 GoDaddy decided not to attempt an initial public offering. In 2008 GoDaddy reported a revenue of $497.9 million, $750 million in 2009. The domain registrar has steadily grower its business within the last 5 years. It is also believed that the company has a strong sales team. The average online order which customers submit on GoDAddy’s website is $26.81, while the average one posted after a the new customers talked to a customer service representative was $65.00. Domain Name Wire reported that before the deal the GoDaddy’s CEO Bob Parsons “owned 78% of the company and employees owned 22% through stock options”. Mr. Parsons, who has got himself involved in a scandal earlier this year and sparked outrage by releasing a video of himself killing an elephant, will remain with GoDaddy as Executive Chairman of the Board. The company president Warren Adelman is the new CEO.

What Would Happen After The Sale? I do not have an inside information about what the new owners of GoDaddy would do with the company. However I’d project that GoDaddy would probably try to expand aggressively in the web hosting service market. The company would try to grow its portfolio of VPS and Dedicated server customers and to grab larger share in the server market. It could also try to become an important player on the market of Cloud hoisting services. Whatever the new owners decide to do GoDaddy could become even bigger within the next few years.

To View Full Article Click Here

With Purchasing SSL Certificates through BigBeagle.com you receive the following great services!

• Includes a FREE website Malware Scanner to monitor your site for malicious links inserted by hackers trying to spread worms, viruses and spyware to your visitors.
• Pay up to 90% LESS and get your certificate FAST!
• Encrypts data transferred to and from your site and protects against session hijacking attacks, including Firesheep.
• Secure UNLIMITED servers. Compare that to other Certification Authorities that charge for licensing on each server.
• Enjoy the backing of established industry standards. There is NO TECHNICAL DIFFERENCE between our certificates and any other major Certification Authority.
• 99.9% browser recognition and up to 256 bit-encryption.
• Get industry-best service and support! Help is always there when you need it.

Need an SSL certificate that supports Intel vPro technology for remote PC management? Check out our Deluxe Certificate