Subscribe:

Sunday, 11 September 2011

Apple revokes DigitNotar certs, Mozilla asks CAs to audit

Apple is the last of the major web browser makers to revoke certificates issued by embattled Dutch-based certificate authority DigiNotar.

In a security advisory released Friday, the Cupertino, Calif.-based computing giant updated Mac OS X 10.6.8 and 10.7.1 to remove DigiNotar from its list of trusted root and extended-validation (EV) SSL certificates. In addition, the patch from Apple configures the Mac platform's default system settings to not trust DigiNotar certificates issued by DigiNotar or any of its partners.

Apple did not, however, release updates for iOS, which powers its iPad and iPhone devices.
Microsoft, Mozilla, Google and Opera already have released updates revoking the DigiNotar certs.
Meanwhile, Adobe said Thursday that it was "in the process of removing the DigiNotar Qualified CA certificate from the Adobe Approved Trust List (AATL)."

And Mozilla, maker of the Firefox browser, is asking all CAs that participate in its root program to audit its PKI infrastructure and systems "to check for intrusion or compromise." In addition, the request, sent Thursday from Kathleen Wilson, owner of Mozilla's CA Certificates Module, asks respondents to ensure that multifactor authentication is in place for all accounts that can issue certificates, as well as confirming that other security controls are deployed.

"Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe," the note said. "Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve."

CAs DigiNotar, which is owned by U.S.-based VASCO, and Jersey City, N.J.-based Comodo have fallen victim this year to hacker attacks. The breaches have resulted in the issuance of counterfeit certificates for such high-profile websites as Google.

Almost all of the victims in both incidents appear to live in Iran.

Wednesday, 7 September 2011

Century Payments Partners with Trustwave to Offer Merchants PCI Compliance Solutions



Century Payments, today selected Trustwave to provide Payment Card Industry Data Security Standard (PCI  DSS) compliance validation solutions to its Level 4 merchants. Trustwave is a leading provider of information security and compliance solutions.

The PCI DSS is the payment card industry security requirement for entities that store, process or transmit cardholder data, and has been endorsed by all the major card brands - Visa, MasterCard Worldwide, Discover Network, American Express and JCB.

In an effort to assist merchants with their compliance efforts, Century engaged Trustwave to provide its merchants access to TrustKeeper®, Trustwave's innovative security and compliance web portal.

Trustwave's TrustKeeper is a revolutionary web portal that supports merchants' compliance efforts, including moving merchants through the complex compliance process with greater ease and efficiency by making the tasks achievable by non-technical users. This helps facilitate PCI DSS compliance validation for merchants or acquirers, ISOs and processors with large merchant populations.

TrustKeeper features PCI Wizard, which simplifies the complex PCI DSS compliance process. Additionally, TrustKeeper Agent helps merchants identify if unencrypted cardholder data or track data is stored, thereby reducing the merchants' risk of card data theft. TrustKeeper also helps merchants complete required vulnerability scans and receive their PCI DSS compliance certificate.

"After careful consideration of other programs, we chose Trustwave because they most aligned with our goals and objectives around data security for our merchant portfolio," said Christopher Justice, president of Century Payments. "Trustwave's industry expertise and merchant compliance program will help our clients validate and maintain their PCI DSS compliance through easy-to-complete steps that any-sized merchant can understand."

"Trustwave is excited to partner with Century Payments, a leading payment processor, because they understand the importance of validating PCI DSS compliance across their merchant portfolio and are ready to provide the resources necessary to help manage the requirements," said Robert J. McCullen, chairman, CEO and president of Trustwave. "Our merchant compliance program provides Century Payments the necessary tools to help lead their merchants through the compliance process in a step-by-step program that translates the difficult tasks of compliance validation into a comprehensible language for merchants of any size."

About Century Payments
Century Payments, Inc. (centurypayments.com) is a nationally recognized leader in the electronic payment processing industry, dedicated to developing the most progressive, dynamic programs to benefit merchants, partners and agents alike. Through white label alliance programs, Century is the fastest growing electronic payments company having boarded over 50,000 merchants in the last three years and processing close to $10 billion in annual volume. In 2011, Century entered into an elite group recognized on the Inc. 500 list as one of the top 20 fastest growing, privately owned businesses for two consecutive years. The company is headquartered in Frisco, Texas.

About Trustwave
Trustwave (
trustwave.com) is a leading provider of on-demand and subscription-based information security and payment card industry compliance management solutions to businesses and government entities throughout the world. For organizations faced with today's challenging data security and compliance environment, Trustwave provides a unique approach with comprehensive solutions that include its flagship TrustKeeper PCI Compliance management software and other proprietary security solutions including SIEM, EV SSL certificates and secure digital certificates. Trustwave has helped hundreds  of thousands of organizations-ranging from Fortune 500 businesses and large financial institutions to small and medium-sized retailers-manage compliance and secure their network infrastructures, data communications and critical information assets. Trustwave is headquartered in Chicago with offices throughout North America, South America, Europe, Africa, Asia and Australia.


The SSL Store Names New Vice President of Operations

September 07, 2011 - St. Petersburg, Florida
The SSL Store Names New Vice President of OperationsThe SSL Store has promoted Kim Barnard to a position as Vice President of Operations. In the position, Ms. Barnard will head both of The SSL Store’s divisions, retail and channel. Ms. Barnard graduated from Indiana University with a BA in Liberal Arts and previously owned a graphic design and web development studio before joining The SSL Store in 2008.

“This executive position was created for Ms. Barnard because the effort and skill which Kim has brought to our organization over the past three years is remarkable," commented The SSL Store CEO John Tuncer. “Since I’ve started working more closely with her, I’ve realized the impressive extent of her contributions to the company and what she’s capable of moving forward."

As VP of Operations, Ms. Barnard will be managing a business focused primarily on reselling SSL Security Certificates, the standardized technology that allows websites to both encrypt transactions (generating https protocol and the lock symbol in browsers) and display third-party accreditation. Ms. Barnard is currently heading an effort to rebrand The SSL Store with a focus on integrity and credibility. With her as a major player, the company has been growing an average of 11 percent each month. In the coming months, Ms. Barnard will be making numerous sales and customer service hires, in the interest of creating a more sophisticated, relationship-based experience for The SSL Store’s customer base (which is primarily composed of small businesses and web development companies but also includes such notable organizations as NASA, Microsoft, the European Union, and the United Nations).

https://www.thesslstore.com/

About the Author – Kent Roberts is the media contact for The SSL Store. He can be reached directly at (727) 820-1161 or kent [at] thesslstore.com.


Source URL:-https://www.thesslstore.com/pressroom/the-ssl-store-names-new-vice-president-of-operations.aspx


Monday, 5 September 2011

Get Wildcard SSL Certificate @ Discount Price & secure your multiple sub domains with single wildcard SSL


Questions? Call
727-388-4240

Wildcard SSL- thesslstore.com offer Wildcard SSL certificate at best prices ever. Secure your multiple sub domains with single wild card ssl certificate.


Get Wildcard SSL Certificate @ Discount Price

Wildcard SSL Certificates:-
  1. GeoTrust True BusinessID Wildcard
  2. If you're looking to secure multiple websites with one server certificate, GeoTrust True BusinessID Wildcard SSL Certificate is the easy, affordable solution. GeoTrust True BusinessID Wildcard SSL Certificate is an ideal solution if you need to secure multiple fully qualified domains that share the same base domain name and reside on the same physical server and share the same second level domain name.
  3. Thawte Wildcard SSL
  4. Thawte Wildcard SSL is an easy, affordable solution if you need to secure multiple fully qualified domains that share the same base domain name, reside on the same physical server, and share the same second level domain name.
  5. RapidSSL Wildcard
  6. RapidSSL Wildcard SSL Certificates allows you to secure unlimited number of sub domains. RapidSSL is industry standard 128 / 256 bit single root SSL certificate. RapidSSL certificates have browser recognition of around 99% including IE 5.01+, Netscape 4.7+ and Mozilla 1+ browsers and many other browsers.

Get Wildcard SSL Certificate @ Discount Price

URL:- https://www.thesslstore.com/wildcardssl-certificates.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“.

Sunday, 4 September 2011

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.

SSL CERTIFICATE ISSUE EXPOSES BUG IN MAC OS X



A bug in the Mac OS X Keychain software was exposed when a recently a Dutch certificate issuing authority has issued a fraudulant SSL certificate for *.google.com. This was caused by a hack of the DigiNotar system and 200 certificates were issued. DigiNotar is one of the largest certificate issuing authorities, it is trusted by a large number of browsers and operating systems.
 
Many vendors have issued fixes for the root certificate and most users are secure against it. Mozilla has issued an update on how to manually remove the certificate, Microsoft has also issued a notice and list of affected operating systems on its security advisory board. However, a bug seems to have surfaced on the Mac OS X. Its Keychain software does not seem to recognize that the DigiNotar certificate has been manually removed.
 
As it turns out, this is because of the EV-SSL (Extended Validation SSL) certificate, Keychain ignores the fact that the certificate has been marked as Untrusted by the user. Keychain should ideally override the EV-SSL with the users preferences but that’s not happening so far.
 
Here’s how to manually disable the certificate in Keychain as there is no official fix for it so far.
 
1.       Open the Keychain Access app (found in /Applications/Utilities or just search for it using the Spotlight menu in the top-right corner of your screen)
2.       Click on System Roots and then Certificates on the left side of the Keychain Access window. In the search bar in the top-right corner of the window, type “diginotar” (without quotation marks)
3.       Double-click on DigiNotar Root CA, click on the triangle next to Trust to expand that section, and then next to “When using this certificate:” select “Never Trust”