Lync Deskphones and Wildcard Certificates

A critical component of any Lync deployment is the deskphone.  While some users may be comfortable with using a headset/PC combo as their primary telephony interface, I've found that most users still prefer a deskphone.

However, getting a Lync deskphone to work with Lync can be a bit tricky if you aren't diligent about following Microsoft best-practices to the letter.  You may have a Lync environment that works perfectly well for computer-based Lync clients, but you may come across various connectivity issues when you plug in a Lync deskphone that does presence and Exchange calendaring. 

I recently came across a client who were having Exchange connectivity issues with their Polycom CX600 phones.  The Polycom CX600 is likely the most popular Lync deskphone. It provides a very slick interface into Lync and Exchange so you can see your presence, contacts and upcoming meeting information. It is also very cost-effective compared to other similar products.

When users signed into Lync on their CX600 (either via keypad or USB-PC integration), they were soon presented with the following error:
 

Microsoft Exchange integration unavailable.  Connection to Exchange is unavailable due to invalid network credentials.

The CX600 uses Exchange Web Services (EWS) and autodiscover to find the connection to Exchange.  If there are issues with either service, it will pretty much guarantee that the CX600 won't connect.  I verified that both EWS and autodiscover were working properly.

When I reviewed the certificate loaded on the Exchange Client Access Server, I saw that the common name (CN) was set to their public domain (ie. contoso.com).  The Subject Alternate Names (SAN) included all the required names.  Microsoft Lync documentation recommends that you do not use certificates with the CN set to a wildcard domain name.  You CAN use wildcards in the SAN, but the CN really should be a valid name.  In this case contoso.com is the same as *.contoso.com. 

The client replaced the certificate with one whose CN matched the externally accessible name of the CAS server (owa.contoso.com) as reported by Exchange.  They issued an IISReset, restarted the CX600 and the error went away.  They now have full connectivity to Exchange via the CX600.

I've seen variations on this many times on both Exchange and Lync.  If you're only using Lync PC clients, you may never notice any issues, but as soon as you bring deskphones and even mobile phones into the mix, these sort of things often come up. 

So as a general rule, if you're creating certificates for Lync or Exchange, DON'T use a Wildcard SSL as the first name.

Source URL:-http://ucken.blogspot.com/2011/09/lync-deskphones-and-exchange.html

The Symantec® NetSure® Protection Plan, the Best in the Biz

Yet another hands down reason to choose a Symantec® SSL product over the other guys. Symantec® now offers an incomparable NetSure® Protection Plan with each and every Secured Sockets Layer (SSL) certificate. The NetSure® Protection Plan is an extended warranty program that keeps its customers and their companies first. It protects SSL Certificate customers against certain losses that possibly resulted from a breach on Symantec®.

This one-of-a-kind warranty extension applies to the VeriSign®, Thawte® & GeoTrust® brands and is just another distinct advantage over the competition.

VeriSign SSL Certificates now include up to a whopping $1,500,000 of NetSure® protection…just to give you a peace of mind and to show you that they truly believe that they are the best security company out there. They truly put their money where their mouth is.

The True Symantec® Advantage

This dramatic increase in warranty coverage across all of the different Symantec® SSL products is a true testament to their confidence in their products and provides VeriSign®, Thawte®, and GeoTrust® customers with the level of trust and security they have come to expect only from Symantec® and The SSL Store.

The New Warranty Limits
The new warranty limits for NetSure® protected SSL certificates are as follows and coverage applies to the following certificates issued on or after July 30th, 2011:

VeriSign Trust Network Certificates SECURE SITE WITH EXTENDED VALIDATION SECURE SITE PRO WITH EXTENDED VALIDATION USD $1,500,000 SECURE SITE PRO CERTIFICATE USD $1,250,000 SECURE SITE CERTIFICATE USD $1,000,000 WILDCARD SSL CERTIFICATE USD $500,000 ANY VERISIGN TRUST NETWORK CERTIFICATE SUBJECT TO THE LICENSED CERTIFICATE OPTION USD $10,000 **CODE SIGNING CERTIFICATES ISSUED PURSUANT TO CODE SIGNING  PORTAL ACCOUNTS ARE NOT CONSIDERED NETSURE CERTIFICATES USD $0 Thawte Certificates THAWTE SSL WEB SERVER CERTIFICATE WITH EXTENDED VALIDATION USD $750,000 THAWTE SGC SUPERCERT USD $500,000 THAWTE SSL WEB SERVER CERTIFICATE USD $250,000 THAWTE WILDCARD SSL CERTIFICATE USD $125,000 THAWTE SSL123 CERTIFICATE USD $100,000 THAWTE CODE SIGNING CERTIFICATE USD $50,000 Geotrust Certificates GEOTRUST TRUE BUSINESSID WITH EXTENDED VALIDATION USD $500,000 GEOTRUST TRUE BUSINESSID GEOTRUST ENTERPRISE SSL STANDARD CERTIFICATE GEOTRUST ENTERPRISE SSL PREMIUM CERTIFICATE USD $250,000 GEOTRUST TRUE BUSINESSID WILDCARD GEOTRUST ENTERPRISE SSL WILDCARD CERTIFICATE USD $250,000 GEOTRUST TRUE BUSINESSID WILDCARD GEOTRUST ENTERPRISE SSL WILDCARD CERTIFICATE USD $125,000 GEOTRUST QUICK SSL PREMIUM CERTIFICATE USD $100,000 CERTIFICATES ISSUED PURSUANT TO GEOROOT ACCOUNTS ARE NOT  CONSIDERED NETSURE CERTIFICATES USD $0 RapidSSL Certificates RAPIDSSL CERTIFICATE USD $10,000 RAPIDSSL ENTEPRISE CERTIFICATE USD $10,000 RAPIDSSL WILDCARD SSL CERTIFICATE USD $5,000

Please contact us for more information on the NetSure® Extended Warranty Protection Plan.

Source URL:-https://www.thesslstore.com/support/symantec-netsure-protection-plan.aspx

Google, Mozilla and Microsoft ban the DigiNotar Certificate Authority in their browsers

 Summary:- Google, Mozilla and Microsoft have banned the DigiNotar Certificate Authority in their browsers.

With the DigiNotar saga continuing, it’s time to summarize some of the current events surrounding it.

According to multiple blog posts, Google, Mozilla and Microsoft have already banned the DigiNotar Certificate Authority in their browsers. This preemptive move comes as a direct response to the mess that DigiNotar created by issuing over 200 rogue certificates for legitimate web sites and services — see a complete list of the affected sites and services.

Earlier this week, Google reported of attempted man-in-the-middle attacks executed against Google users, and most recently, TrendMicro offered insights into a large scale spying operation launched against Iranian web users.

According to TrendMicro:

From analysis of Smart Protection Network data, we see that a significant part of Internet users who loaded the SSL certificate verification URL of Diginotar were from Iran on August 28, 2011. On August 30, 2011 most traffic from Iran disappeared and on September 2, 2011 about all of the Iranian traffic was gone and Diginotar received mostly Dutch Internet users, as expected.

These aggregated statistics from Trend Micro Smart Protection Network clearly indicates that Iranian Internet users were exposed to a large scale man-in-the-middle attack, where SSL encrypted traffic can be decrypted by a third party. For example: a third party probably was able to read all e-mail communication an Iranian Internet user has sent with his Gmail account.

Meanwhile, the Dutch government issued a statement saying that it “cannot guarantee the security of its own websites” and is “taking over the company’s (DigiNotar) operations.”

“the user of government sites no longer has the guarantee … that he is on the site where he wanted to be,” Interior Minister Piet Hein Donner said at a pre-dawn press conference.

Moreover, Illinois-based VASCO, which owns the Dutch-based DigiNotar issued the following statement:

DigiNotar detected an intrusion into its Certificate Authority (CA) infrastructure, which resulted in the fraudulent issuance of public key certificate requests for a number of domains, including Google.com. Once it detected the intrusion, DigiNotar has acted in accordance with all relevant rules and procedures. At that time, an external security audit concluded that all fraudulently issued certificates were revoked. Recently, it was discovered that at least one fraudulent certificate had not been revoked at the time.  After being notified by Dutch government organization Govcert, DigiNotar took immediate action and revoked the fraudulent certificate.

Who’s behind the attacks? According to the Tor Project, clues were found in one of the certificates, including messages in Farsi:

Of particular note is this certificate:CN=*.RamzShekaneBozorg.com,SN=PK000229200006593,OU=Sare Toro Ham Mishkanam,L=Tehran,O=Hameye Ramzaro Mishkanam,C=IR

The text here appears to be be an entry like any other but it is infact a calling card from a Farsi speaker. RamzShekaneBozorg.com is not a valid domain as of this writing.Thanks to an anonymous Farsi speaker, I now understand that the above certificate is actually a comment to anyone who bothers to read between the lines:”RamzShekaneBozorg” is “great cracker“,”Hameyeh Ramzaro Mishkanam” translates to “I will crack all encryption“,”Sare Toro Ham Mishkanam” translates to “i hate/break your head“

VASCO, the owner of DigiNotar said it plans to indefinitely suspend the sale of its traditional and extended-validation (EV) SSL certificates, until the case is solved. “The company will only restart its SSL and EV SSL certificate activities after thorough additional security audits by third-party organizations“.

Source URL:-http://www.zdnet.com/blog/security/google-mozilla-and-microsoft-ban-the-diginotar-certificate-authority-in-their-browsers/9337

SSL for the Rest of Us

Recently, a certificate authority (CA) named Diginotar mistakenly issued valid wildcard SSL certificates for some major websites such as Google, Mozilla, Yahoo, WordPress and the Tor Project. Security experts and application vendors considered this a serious threat to the essential web of trust that the Internet rests upon, and have moved to invalidate Diginotar-issued certificates in their software products.

Many of our clients operate e-commerce applications, and for them, purchasing an SSL certificate is an essential part of doing business online. However, it seems to me that some clients and readers may not fully understand what an SSL Certificate is or why they’re needed. This blog post will hopefully help to explain that.

What is SSL?

The Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are protocols that allow two parties to communicate over a network without any other parties listening to or tampering with that conversation. These protocols are part of a much larger field of computer science known as cryptography.

Let’s say that Bob is doing some online shopping at Alice’s e-commerce store, mirrorsbyalice.com, and finds a product he wants to purchase. Bob needs to send Alice his credit card information privately so that nobody but Alice gets it. Alice, being quite tech savvy, knows that there are two primary ways this can be done:

• Symmetric (conventional) cryptography in which Bob and Alice share a secret key that can be used to encrypt or decrypt the credit card data.
  
  
• Public key (asymmetric) cryptography in which there are two keys, one public and one private. The public key can be used to encrypt the data and only the private key can be used to decrypt it.

Conventional cryptography suffers from a major problem in this scenario. How do Bob and Alice exchange the secret key securely? Well this is the same problem they were trying to solve in the first place with the credit card data! Alice reasons that the only viable method to use for e-commerce is public key cryptography. So Alice generates a private/public key pair and sends Bob the public key so he can use it to encrypt his credit card data.

But wait! Bob is no dunce. How does he know that the public key he receives was sent by the real Alice? This is where certificates come into play.

SSL Certificates

An SSL certificate associates a public key with some sort of identifying information for the party (Subject) that sent it. Certificates are issued and signed by a Certificate Authority (CA). Technically, anybody can issue and sign a certificate. Alice could even act as her own CA and generate something called a self-signed certificate. Although self-signed certificates accomplish the goal of ensuring that the conversation between Bob and Alice is encrypted, Bob still has no way of ensuring that he’s talking to The Real Alice™, and therefore they are not good to use in e-commerce transactions. If Alice wants to assure her shoppers that the certificate really came from her, then she needs to purchase one from a trusted third-party CA.

Certificate Authorities and Certificate Chains

The Internet is built on a web of trust. Each certificate requires the issuer to verify and assure the identity of the certificate subject. As mentioned, this is usually done by a trusted third-party CA. However, the question naturally arises, who verifies and assures the identity of the issuer (CA)? The answer is that there is no one central authority. A number of companies over the course of time have established themselves as Root-Level Certificate Authorities. These companies, such as Thawte andVeriSign, have self-signed certificates and most applications and operating systems are pre-configured to trust them. CAs can also sign each others certificates, effectively delegating authority to another CA. The hierarchy of certificates leading back to a Root-Level CA is known as a Certificate Chain.

Hopefully now you can appreciate the gravity and consequences of the story that opened this post. If one of those trusted CAs gets compromised and issues a valid certificate for a well-known organization, then anyone who has one of those certificates can pretend to be that organization and intercept private communications.

Certificate Types and Certificate Signing Requests (CSR)

Alice realizes that she needs to get a certificate issued by a trusted CA in order for Bob to feel secure in sending her his credit card information. After some research, she realizes she needs to make a few decisions first. Specifically, she needs to decide what kind of SSL certificate to get, and how she wants to be identified in that certificate.

Although CAs come up with all kinds of names for their SSL offerings, they generally fall into different categories based on the level of identity verification or the number of domains (Common Names) they certify:

By Validation	Description
Domain Validated (DV) SSL	The CA checks only that the applicant owns the domain in question.
Organizationally Validated (OV) SSL	The CA verifies that the applicant is a legitimate business by examining business credentials and physical address.
Extended Validation SSL	The CA performs an extensive verification and background check on the applicant. Turns the address bar in browsers green.
By Common Name	Description
Standard	This is the standard, good for one domain name.
Wildcard	Valid for *.example.com. Which includes any subdomain (www.example.com, mail.example.com) but NOT the parent domain (example.com)
UCC/Multi-domain	Allows for multiple names in a single certificate (www.example.com and example.com and someotherdomain.com)

Alice decides to purchase a standard, domain-validated certificate for www.mirrorsbyalice.com. She first generates her private/public key pair on the server that hosts her website. While keeping the private key secret, she then generates a special message called a Certificate Signing Request (CSR) which contains information identifying her business and the public key she just created. She sends the CSR along with any other proofs of identity required to the Certificate Authority. If approved, the CA will send back a certificate that has been digitally signed with the private key of the CA.

Bob’s Browser

With certificate in hand, Alice installs it on her web server and configures her e-commerce application to use it for checkouts. Bob can now click on the checkout button on the website. His web browser will change the communication protocol from HTTP to HTTPS, indicating that it is now communicating with Alice’s website over the Secure Sockets Layer. Since Alice is using a certificate issued by a CA that Bob’s browser trusts, the location bar in his web browser changes to Blue and a little lock appears. Bob now feels much safer about sending his credit card and other personal information to Alice.

Conclusion

SSL/TLS protocols can be used any time a message needs to be sent privately over a network, not just for web browsing. The same technology is used by email servers, FTP servers, and several other internetworking services. As you can see, trust is an integral part of the operation of the Internet, and breaches and misuses of that trust can have far reaching implications. With regard to the Diginotar incident mentioned at the top, many major software vendors have removed this CA from their list of trusted authorities. As an end user, if you see a security update for your browser come through anytime soon, make sure you act on it.

Source URL:-http://blog.nexcess.net/2011/09/02/ssl-for-the-rest-of-us/