Java SecurityException : signer information does not match

Java SecurityException : signer information does not match

Cause :

It is happening due to loading of same jar  with multiple versions .

Example :

 In one of my case I faced the same issue.  I have "httpclient-4.1.2.jar" and "httpclient-4.0.jar" jars in my lib folder . Due to this , while loading the jar files , http client is verifying the signature signed by apache. It is getting error due to different certificates from two jar files.

Solution:

 Just remove the one of the jar , in my case I removed old version jar.

Threads in Java

What is Thread ?

A thread is an independent sequential path of execution within a program

Race Condition:

A race condition occurs when two or more threads simultaneously update the same value, and as a consequence, leave the value in an undefined or inconsistent state.

Thread Creation:

1.Inheritence- Heavy Implementation of Thread

– extending the java.lang.Thread class

2.Interface- Light Version of Thread Creation

– implementing the java.lang.Runnable  interface

Thread States:

Thread is a lightweight process, the smallest unit of scheduled execution. Instance of the Thread class in Java 6 could be in one of the following states:

• new,

• runnable,
• timed waiting,
• waiting,

• blocked,
• terminated.

These states are Java Virtual Machine (JVM) states reported by JVM to Java programs. At any given point in time thread could be in only one state.

Protocol state machine example - Thread states and life cycle in Java 6

New is the thread state for a thread which was created but has not yet started.

At the lower operating system (OS) level, JVM’s runnable state could be considered as a composite state with two substates. When a thread transitions to the runnable JVM state, the thread first goes into the ready substate. Thread scheduling decides when the thread could actually start, proceed or be suspended. Thread.yield() is explicit recommendation to thread scheduler to pause the currently executing thread to allow some other thread to execute.

A thread in the runnable state is executing from the JVM point of view but in fact it may be waiting for some resources from the operating system.

Timed waiting is a thread state for a thread waiting with a specified waiting time. A thread is in the timed waiting state due to calling one of the following methods with a specified positive waiting time:

• Thread.sleep(sleeptime)
• Object.wait(timeout)
• Thread.join(timeout)
• LockSupport.parkNanos(timeout)
• LockSupport.parkUntil(timeout)

A thread is in the waiting state due to the calling one of the following methods without timeout:

• Object.wait()
• Thread.join()
• LockSupport.park()

Note, that thread in the waiting state is waiting for another thread to perform a particular action. For example, a thread that has called Object.wait() on an object is waiting for another thread to call Object.notify() or Object.notifyAll() on that object. A thread that has called Thread.join() is waiting for a specified thread to terminate. It means that waiting state could be made a composite state with states corresponding to these specific conditions.

Thread is in the blocked state while waiting for the monitor lock to enter a synchronized block or method or to reenter a synchronized block or method after calling Object.wait().

A synchronized statement or method acquires a mutual-exclusion lock on behalf of the executing thread, executes a block or method, and then releases the lock. While the executing thread owns the lock, no other thread may acquire the lock and is blocked waiting for the lock.

After thread has completed execution of run() method, it is moved into terminated state.

Thread Priorities:

Thread has its own priority depends on the priority we set to thread. If not priority set to thread then it will take DEFAULT_PRIORITY( which is 5). Priority starts from 1-10. where 10 is high priority.

But notable thing here is , we cannot guaranteed that threads can be executed in the order of priority or on priority basis. It all depends on the Thread Scheduler to pick and manage .

Thread WAIT States:

Thread will go to WAITING state depends on the functions we call on threads. We have methods like sleep(x),wait(x),yield(),join(x) to make thread to take some rest or give the priority to other threads.

Sleep ->

When we call sleep on thread , it will go to TIMED_WAITING state and will not give a chance to run other thread. While sleeping , thread will not release the lock .

*  you can reach this site for differences between sleep and yield and wait.

  http://javarevisited.blogspot.sg/2011/12/difference-between-wait-sleep-yield.html

WAIT() & NOTIFY()

When a thread calls the wait() method:

1. The thread releases the lock for the object.
2. The state of the thread is set to blocked.
3. The Thread is placed in the wait set for the object

When a thread calls the notify() method:

1.  An arbitrary thread is picked from the list of threads in the wait set.
2. Moves the selected thread from the wait set to the entry set.
3. Sets the state of the selected thread from blocked to runnable.

Wait ,Notify and NotifyAll are called inside the synchronized block because this mechanism is used for inter-thread communication. These methods are instance methods in Object class because java by default providing the feature of waiting on every user defined class which extends Object.

Wait will not the keep the LOCK, only sleep will keep the LOCK when it is in sleeping/TIMED_WAITING state.Locks are made available on per Object basis.

Starvation

Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress. This happens when shared resources are made unavailable for long periods by "greedy" threads. For example, suppose an object provides a synchronized method that often takes a long time to return. If one thread invokes this method frequently, other threads that also need frequent synchronized access to the same object will often be blocked.

• Causes of Starvation in Java

Threads with high priority swallow all CPU time from threads with lower priority

Threads are blocked indefinitely waiting to enter a synchronized block

Threads waiting on an object (called wait() on it) remain waiting indefinitely

How to Avoid Starvation:

Fairness-

Use Locks with proper time out.

Locks & Conditions

These are improvised version from synchronized blocks which gives fairness and reentrance.

ReentrantLock

The same thread can acquire the same lock multiple times, but you have to make sure you release the lock the same number of times that you acquire it. This Feature we cannot achieve using synchronization. TO achieve fairness with this,

The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favour granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation. Note however, that fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock. Also note that the untimed tryLock method does not honour the fairness setting. It will succeed if the lock is available even if other threads are waiting.

Locks can use Fairness policy if set true in constructor.

It is recommended practice to always immediately follow a call to lock with a try block, most typically in a before/after construction such as:

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

public void m() {
     lock.lock();  // block until condition holds
     try {
       // ... method body
     } finally {
       lock.unlock()
     }
   }
 }

Difference between ReentrantLock and synchronized keyword in Java

Though ReentrantLock provides same visibility and orderings guaranteed as implicit lock, acquired by synchronized keyword in Java, it provides more functionality and differ in certain aspect. As stated earlier,  main difference between synchronized and ReentrantLock is ability to trying for lock interruptibly, and with timeout. Thread doesn’t need to block infinitely, which was the case with synchronized. Let’s see few more differences between synchronized and Lock in Java.

1.  Another significant difference between ReentrantLock and synchronized keyword is fairness. synchronized keyword doesn't support fairness. Any thread can acquire lock once released, no preference can be specified, on the other hand you can make ReentrantLock fair by specifying fairness property, while creating instance of ReentrantLock. Fairness property provides lock to longest waiting thread, in case of contention.

2.  Second difference between synchronized and Reentrant lock is tryLock() method. ReentrantLock provides convenient tryLock() method, which acquires lock only if its available or not held by any other thread. This reduce blocking of thread waiting for lock in Java application.

3.  One more worth noting difference between ReentrantLock and synchronized keyword in Java is, ability to interrupt Thread while waiting for Lock. In case of synchronized keyword, a thread can be blocked waiting for lock, for an indefinite period of time and there was no way to control that. ReentrantLock provides a method called lockInterruptibly(), which can be used to interrupt thread when it is waiting for lock. Similarly tryLock() with timeout can be used to timeout if lock is not available in certain time period.

4.  ReentrantLock also provides convenient method to get List of all threads waiting for lock.

So, you can see, lot of significant differences between synchronized keyword and ReentrantLock in Java. In short, Lock interface adds lot of power and flexibility and allows some control over lock acquisition process, which can be leveraged to write highly scalable systems in Java.

Read more: http://javarevisited.blogspot.com/2013/03/reentrantlock-example-in-java-synchronized-difference-vs-lock.html#ixzz3ARpcjudb

JMS Overview

History:

Before JMS defined by JAVA SUN , there are different specific clients provided by  MQ  . In order to make it more generalize the interaction with QUEUES from java application, SUN introduced/defined JMS API  Interface Specification. In which most of well known QUEUES implemented the JMS API.

What is JMS ?

JMS  is uniform API provided by Java platform which enables developer to work directly with JMS API and need not to worry what is underlying messaging framework. A messaging implementation has to be JMS-compliant in order to be worked upon by JMS APIs.

The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API  for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914. It is a messaging standard that allows application components based on the Java Enterprise Edition (Java EE) to create, send, receive, and read messages. It allows the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous.

JMS Analogy

JMS interface API is similar with analogy of JDBC interface API, in case of JDBC we have different databases in JMS case we have different queues.

Most of the application servers like WEBLOGIC, GLASSFISH,JBOSS,WEBSPHERE have their own Queues inside the server.

Example:

Lets talk about the  example of the Glassfish server, it have OPEN MQ  and JMS implemented . So we can directly access OPEN MS from Glassfish server using JMS. We can also integrate the third party Queues like ACTIVE-MQ   into GLASSFISH server using Resource Adapter module of Glassfish .

Note:

JMS is one of the option for accessing the queues. We also have other options like QUEUE specific client jar and Spring supported jar.

What is JMS used for ?

It is used to access queues in Application servers . Most of the application servers have their own queue s  available with server.

1. Websphere - IBM MQ
2. GlassFish- Open MQ
3. Jboss - Jboss MQ

Most widely/known  MQ is ActiveMQ( built on Java), IBM MQ, MS MQ.

JMS Elements/Terminology :

JMS provider

An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM.

JMS client

An application or process that produces and/or receives messages.

JMS producer/publisher

A JMS client that creates and sends messages.

JMS consumer/subscriber

A JMS client that receives messages.

JMS message

An object that contains the data being transferred between JMS clients.

JMS queue

A staging area that contains messages that have been sent and are waiting to be read (by only one consumer). Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. A JMS queue only guarantees that each message is processed only once.

JMS topic

A distribution mechanism for publishing messages that are delivered to multiple subscribers.

What are JMS Models ?

Models

The JMS API supports two models:

• Point-to-point

• Publish and subscribe

Point-to-point model

In point-to-point messaging system, messages are routed to an individual consumer which maintains a queue of "incoming" messages. This messaging type is built on the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and the receiving clients extract messages from the queues established to hold their messages. While any number of producers can send messages to the queue, each message is guaranteed to be delivered, and consumed by one consumer. Queues retain all messages sent to them until the messages are consumed or until the messages expire. If no consumers are registered to consume the messages, the queue holds them until a consumer registers to consume them.

Publish/subscribe model

The publish/subscribe model supports publishing messages to a particular message topic. Subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscriber knows about each other. A good analogy for this is an anonymous bulletin board.

• Zero or more consumers will receive the message.

• There is a timing dependency between publishers and subscribers. The publisher has to create a message topic for clients to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected will be redistributed whenever it reconnects.

JMS provides a way of separating the application from the transport layer of providing data. The same Java classes can be used to communicate with different JMS providers by using the Java Naming and Directory Interface (JNDI) information for the desired provider. The classes first use a connection factory to connect to the queue or topic, and then use populate and send or publish the messages. On the receiving side, the clients then receive or subscribe to the messages.

Its an overview of the JMS API programming model.

Code Explanation:

1. First create the Destination (Queue) in Application Server ( GlassFish).

2. Create Connection Factory for that Queue to access from JMS API.

3. With these two steps GlassFish server will be used for Queue connection management.
4. Create the MDB (Message Driven Bean ) in Enterprise Application(EJB ear file).
5. This MDB will act as Consumer Bean to access and consume/receive message from Queue.
6. Here we used session beans for Producer bean in EJB to produce messages to Queue.

Sending Message:

ConnectionFactory>Connection>Session>MessageProducer>send

Message Producer in EJB Session Bean:

Receive Message:

ConnectionFactory>Connection>Session>Message Consumer>receive

Listener Implementation model.

-------------------------------------------------

package sessionbeans;

import javax.annotation.Resource;

import javax.ejb.Stateless;

import javax.inject.Inject;

import javax.jms.JMSConnectionFactory;

import javax.jms.JMSContext;

import javax.jms.Queue;

/**

 * Message Producer Session Bean

 * @author Kumar

 */

@Stateless

public class ProducerSB implements ProducerSBLocal

{

    @Resource(mappedName = "jms/kumarqueue")

    private Queue kumarqueue;

    @Inject

    @JMSConnectionFactory("jms/kumarQConFactory")

    private JMSContext context;

    private void sendJMSMessageToKumarqueue(String messageData) {

        context.createProducer().send(kumarqueue, messageData);

    }

   

   

   

    public void sendMessageToQueue(String message)

    {

        sendJMSMessageToKumarqueue(message);

    }

  

}

Message Consumer in EJB-3.0 Message Driven Bean

/*

 * To change this license header, choose License Headers in Project Properties.

 * To change this template file, choose Tools | Templates

 * and open the template in the editor.

 */

package messagedrivenbeans;

import java.util.logging.Level;

import java.util.logging.Logger;

import javax.ejb.ActivationConfigProperty;

import javax.ejb.MessageDriven;

import javax.jms.JMSException;

import javax.jms.Message;

import javax.jms.MessageListener;

import javax.jms.TextMessage;

/**

 *

 * @author Kumar

 */

@MessageDriven(activationConfig = {

    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),

    @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "jms/kumarqueue")

})

public class ConsumerMessageDrivenBean implements MessageListener {

   

    public ConsumerMessageDrivenBean() {

    }

   

    @Override

    public void onMessage(Message message)

    {

        TextMessage textMessage = (TextMessage)message;

       

        for (int i = 0; i < 10; i++)

        {

            try {

                System.out.println(i + ":" + textMessage.getText());

                Thread.sleep(1000);

            } catch (JMSException ex) {

                Logger.getLogger(ConsumerMessageDrivenBean.class.getName()).log(Level.SEVERE, null, ex);

            } catch (InterruptedException ex) {

                Logger.getLogger(ConsumerMessageDrivenBean.class.getName()).log(Level.SEVERE, null, ex);

            }

        }

       

    }

   

}//End of Class

JMS Advantages :

JMS is asynchronous in nature. Thus not all the pieces need to be up all the time for the application to function as a whole. Even if the receiver is down the MOM will store the messages on it's behalf and will send them once it comes back up. Thus at least a part of application can still function as there is no blocking.

What are different type of messages supported in JMS API ?

Message, TextMessage, BytesMessage, StreamMessage, ObjectMessage, MapMessage are the different messages available in the JMS API

Where to use ?

JMS is typically used in the following scenarios

1. Enterprise Application Integration: - Where a legacy application is integrated with a new application via messaging.

2. B2B or Business to Business: - Businesses can interact with each other via messaging because JMS allows organizations to cooperate without tightly coupling their business systems.

3. Geographically dispersed units: - JMS can ensure safe exchange of data amongst the geographically dispersed units of an organization.

4. One to many applications: - The applications that need to push data in packet to huge number of clients in a one-to-many fashion are good candidates for the use JMS. Typical such applications are Auction Sites, Stock Quote Services etc.

How to Implement JMS  in different Technologies ?

We have different approaches for accessing queues using JMS .

1. Spring Integration approach

2. EJB - Message Driven Bean Approach

Resources:

http://www.youtube.com/watch?v=NAdrThcQkwQ

http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html

MOM vs ESB

MOM - Message Oriented Middleware

ESB - Enterprise Service BUS

I consider MOM a building block for ESB solutions. In fact, ESB solutions reach their own loose coupling and asynchronous communication capabilities, just using the paradigm offered by the specific MOM implementation.

Therefore, MOMs represent solutions for data/events distribution at customized level of QoSs (according to the specific vendor implementation), instead ESBs represent solutions providing capabilities to realize complex orchestrations in a SOA scenario (where we have multiple providers offering their services, and multiple consumers interested in consuming the services offered by the first ones).

Complex orchestrations imply communication between legacy systems, everyone of these with its own data domain representation (rules and services on specific data) and its own communication paradigm (one consumer interact with the ESB using CORBA, another one using WS, and so on).

It is clear that ESB represents a more complex architectural solution aimed to provide the abstraction of data-bus (such as the electronic buses that everyone have in his own pc), able to connect a plethora of service providers to a not well specified plethora of service consumers, hiding heterogeneity in (i) data representation and (ii) communication.

ESB is just yet another buzzword, as is SOA 2.0.

You can have a ESB system easily implemented with normal Web Services with a queue behind them. You can have message routing and or orchestration with SOA 1.0 (Tibco{EMS}, BizzTalk), one things does not stop the other really. More importantly, it is the semantics given to the messages exchanged in the system that play an important role, in this case events. Messages as events, are triggers about something that happened in your system, so the context is different.

ESB:

 MOM :

MessageQueue vs Message Broker

MQ is a solution for application-to-application communication services regardless of where your applications or data reside. Whether on a single server, separate servers of the same type, or separate servers of different architecture types, MQ facilitates communications between applications by sending and receiving message data via messaging queues. Applications then use the information in these messages to interact with Web browsers, business logic, and databases. MQ provides a secure and reliable transport layer for moving data unchanged in the form of messages between applications but it is not aware of the content of the messages. MQ uses a set of small and standard application programming interfaces (APIs) that support a number of programming languages, including Visual Basic, NATURAL, COBOL, Java, and C across all platforms.

Message Broker is built to extend MQ, and it is capable of understanding the content of each message that it moves through the Broker. Customers can define the set of operations on each message depending on its content. The message processing nodes supplied with Message Broker are capable of processing messages from various sources, such as Java Message Service (JMS) providers, HyperText Transfer Protocol (HTTP) calls, or data read from files. By connecting these nodes with each other, customers can define linked operations on a message as it flows from one application to its destination.

Message Broker can do the following:

    * Matches and routes communications between services

    * Converts between different transport protocols

    * Transforms message formats between requestor and service

    * Identifies and distributes business events from disparate sources

Together, MQ and Message Broker deliver a comprehensive publish and subscribe facility, connecting Message Broker’s broad transport and format support to MQ’s messaging backbone. Message Broker extends the MQ publish and subscribe functionality with advanced function such as content-based publish and subscribe by means of an enhanced Publication node. The two products share a common publish and subscribe domain for topic- and content-based operations

Java Perspective :

===============

Message Broker - The message-oriented middleware server that hosts messaging destinations (i.e., queues and topics) for the purposes of asynchronous communication. Sometimes known as a queue manager

Message Queue - A messaging destination that uses a queue data structure to hold messages and is hosted by the message broker. The alternative to a queue is a topic which provides publish/subscribe semantics.

Resource Adapter - A Java EE Resource Adapter is a component that allows communication between a Java EE application and an enterprise information system such as a database server, a messaging server, a CRM server, an ERP server, etc.

javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name

Caused by: javax.net.ssl.SSLProtocolException: handshake alert:  unrecognized_name

at sun.security.ssl.ClientHandshaker.handshakeAlert(Unknown Source)

at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)

at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)

at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)

at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)

at java.net.URL.openStream(Unknown Source)

Issue :

I got this exception when I am trying to connect to WebService using https. You may also get this while connecting to any HTTPS url .

Solution:

It is issue with Server , because in their certificate the common name doesn’t match with  url domain.

It's possible to put multiple hostnames in a modern certificate and just use that one certificate in the default vhost, there are many hosting providers who are hosting for too many sites on a single address for that to be practical for them

In two ways we can fix the issue :

Http Client Side:

Java 7 introduced SNI support which is enabled by default. I have found out that certain misconfigured servers send an "Unrecognized Name" warning in the SSL handshake which is ignored by most clients... except for Java.

As workaround, I suggest to set the jsse.enableSNIExtension property. To allow your programs to work without re-compiling, run your app as:

java -Djsse.enableSNIExtension=false yourClass

The property can also be set in the Java code, but it must be set before any SSL actions. Once the SSL library has loaded, you can change the property, but it won't have any effect on the SNI status. To disable SNI on runtime (with the aforementioned limitations), use:

System.setProperty("jsse.enableSNIExtension", "false");

The disadvantage of setting this flag is that SNI is disabled everywhere in the application. In order to make use of SNI and still support misconfigured servers:

1. Create a SSLSocket with the host name you want to connect to. Let's name this sslsock.
2. Try to run sslsock.startHandshake(). This will block until it is done or throw an exception on error. Whenever an error occurred in startHandshake(), get the exception message. If it equals to handshake alert: unrecognized_name, then you have found a misconfigured server.
3. When you have received the unrecognized_name warning (fatal in Java), retry opening a SSLSocket, but this time without a host name. This effectively disables SNI (after all, the SNI extension is about adding a host name to the ClientHello message).

HttpServer Side:

On the server side we have to create certificate with matching Domain name as Server Name or define where we have ServerName / ServerAlias as same name mentione din certificate common name.

Ref:

1. https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

2.https://support.roambi.com/hc/en-us/articles/200858194-Cannot-verify-SSL-portal-due-to-error-javax-net-ssl-SSLProtocolException-handshake-alert-unrecognized-name

3.http://en.wikipedia.org/wiki/Server_Name_Indication

Browser ssl certificate validation

1. How SSL works

                 Please check this link-->  How SSL Works

2. How browser verifies certificate

It has 3 ways to verify the SSL certificate from server:

1. It verifies with local trust store
2. Verifies using CRL- (Explained Below)
3. Verifies using OCSP (Explained Below)
4. Verifies using  SCVP( Not Supported as of today) Spec defined as of now.

3. When  certificate compromise

It is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements, such as publication of false documents, mis-representation of software behavior, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen).

4. Certificate Revocation List - OCSP-Online Certificate Status Protocol

Today we did an announcement of some work we have been doing with CloudFlare to speed up SSL for all of our customers through some improvements to our revocation infrastructure.

One of the things that come up when talking about this is how each of the browsers handles revocation checking, I thought it might be useful to put together a quick post that talks about this to clear up some confusion.

The first thing that’s important to understand is that all major browsers do some form of revocation checking, that includes Opera, Safari, Chrome, Firefox and Internet Explorer.

Let’s talk about what that means, the IETF standards for X.509 certificates define three ways for revocation checking to be done, the first is Certificate Revocation Lists (CRLs), next there is the Online Certificate Status Protocol (OCSP) and finally there is something called Simple Certificate Validation Protocol (SCVP).

In the context of browsers we can ignore SCVP as no browser implements them; this leaves us with CRLs and OCSP as the standards compliant ways of doing revocation checking.

All of the above browsers support these mechanisms, in addition to these standard mechanisms Google has defined a proprietary certificate revocation checking scheme called CRLsets.

If we look at StatCounter for browser market share that means today at least 64.84% (its likely more) of the browsers out there are doing revocation checking based on either OCSP or CRLs by default.

This means that when a user visits a website protected with SSL it has to do at least one DNS look-up, one TCP socket and one HTTP transaction to validate the certificate the web server presents and more likely several of these.

This is important because of the way revocation checking needs to be done, you need to know if the server you are talking to really is who they say they are before you start to trust them – that’s why when browsers do OCSP and CRLs they do this validation before they download the content from the web page.

This means that your content won’t be displayed to the user until this check happens and this can take quite a while.

For example in the case of IE and Chrome (when it does standards based revocation checking on Windows) it uses CryptoAPI which will time-out after 15 seconds of attempting to check the status of a certificate.

The scary part is that calls to this API do actually time out and when they do this delay is experienced by the users of your website!

So what can you do about it? It’s simple really you have to be mindful of the operational capacity and performance of the certificate authority you get your certificate from.

Check out this monitoring portal I maintain for OCSP and this one I maintain for CRLs, you will see GlobalSign consistently outperforms every other CA for the performance of their revocation infrastructure in most cases it’s nearly 6x as fast and in others is much more than that.

The other thing to understand is that today the default behavior of these browsers when checking the status of a certificate via OCSP or CRLs is to do what is often referred to as a “soft-revocation failure”.

This basically means that if they fail for any reason to check the status of a certificate (usually due to performance or reliability issues) they will treat the certificate as good anyways. This is an artifact of CAs not operating sufficiently performant and reliable infrastructure to allow the browsers to treat network related failures critically.

Each of these browsers all have options you can use to enable “hard” or “strict” revocation checking but until the top CAs operate infrastructure that meets the performance and reliability requirements of the modern web no browser will make these the default.

Finally its also important to understand that even with this “soft-failure” your website experiences the performance cost of doing these checks.

5. Conclusion:

Now we have two online checking protocols for Certificate from browsers:

1. OCSP - Online Certificate Status Protocol- Most browsers supported
2. SCVP- Simple Certificate Validation Protocol- Most of the Browsers not yet Implemented.

6. References:

http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html

http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html