How to Load Test CDPs With JMeter
How to Load Test CDPs With JMeter
This article explains the steps of how to load test CDPs, distribution points for digital security certificates, using JMeter.
Join the DZone community and get the full member experience.Join For Free
Sensu is an open source monitoring event pipeline. Try it today.
Secure websites use digital certificates to confirm they are secure. One of the ways to check the revocation status of these certificates is by CRLs (Certificate Revocation Lists) (the more common way is OCSP, which you can learn how to load test here). Access to the CRL is provided to users through CRL Distribution Points (CDPs). The CDPs are represented by a URL, for example, an HTTP URL or an LDAP URL. This blog post will explain how to load test these CDPs.
A digital certificate is a document issued to websites by a Certification Authority (CA), which confirms the security of the website. The certificates are managed in a PKI (Public key infrastructure). The PKI defines the policy for issuing certificates, revoking them and checking their validity, which is confirmed by the CA. Checking certificate revocation is necessary if the client's certificate has been compromised. If an intruder gets such a certificate they will be able to act as a former certificate owner.
One of the ways to deal check the certificate revocation status is with CRLs, which is a list of certificates revoked by the CA.
Briefly, it works like this:
- A website uses a digital certificate that contains information about the CRL.
- A user comes to the website.
- An app, in our case it is a browser, checks the certificate, finds info about the CRL and downloads it.
- The app checks the CRL and makes a decision about the validity of the certificate and displays it to the user.
For example, if we go to the BlazeMeter website, we will see the green bar to the left of the address.
The bar means that the site uses the https protocol for communication and a certificate is used to agree upon the authenticity of the servers.
We can find out who the issuer of this certificate is. As you can see in the screenshot below, it is issued by the DigiCert SHA2 Secure Server Certification Authority.
Moreover, as you can understand from the screenshot above, there is another Certification Authority. It works as follows: there is one main Certification Authority that issues certificates only for another Certification Authority, for example, a regional Certification Authority. And the regional Certification Authority issues certificates to end users. This hierarchy is called a hierarchical PKI. It is also the most commonly used type of PKI.
Let's return to the blazemeter.com certificate and review its extensions, which are the way a user can obtain the CRL. These are called CDPs - CRL Distribution Points, As you can see in the screenshot below, the certificate contains a CDP Extension, which includes two CDPs with HTTP URL.
These CDPs contain identical CRLs, which provide greater reliability. So, if the first CDP is unavailable, a user can go to the next CDP. If the second CDP is unavailable, any operations depending on a certificate will be prevented, because the certificate will be marked as invalid, and as a consequence, denial of service may occur.
If you follow one of the links, the file containing DigiCert SHA2 Secure Server CA revoked certificates will be downloaded.
In the example above we have several Certification Authorities. These Certification Authorities form the certification chain, which must be passed to confirm the validity of the certificate. So, in addition to checking the CRL of DigiCert SHA2 Secure Server Certification Authority, the CRL of DigiCert Certification Authority need to be checked as well to verify the validity of the DigiCert SHA2 Secure Server Certification Authority certificate. If the CDP of DigiCert SHA2 Secure Server CA is available, but the CDP of DigiCert is not available, the whole chain is marked as unsuccessful, the certificate will be marked as invalid, too.
Therefore, SSL site users who use the CRL verification method constantly keep checking for revocation by download these files. In addition, although a CRL can be cached, they are still very volatile, turning Certification Authorities into a major performance bottleneck.
After receiving the CRL, it is cached and usually updated a few days later. Therefore, we do not get a CRL every time we connect to a protected resource. But if you want, this setting can be adjusted and, for example, the CRL can be updated every hour.
To load test CDPs, we only need to go to the link specified in the CDP extension of the certificate and download the CRL file. As an alternative, you just need a list with CDP URLs that can be provided by the system administrator, who deployed the PKI. But then we will not be able to check the validity of the certificate because we won't have it. Therefore, if you also want to check the availability of the certificates in the CRL, you need these certificates because the checking of the certificate's CDP Extension is part of full validation.
As a rule, and our case is not an exception, HTTP is used to distribute the CRL, but sometimes LDAP or FTP too can be used for CRL distribution.
1. Add the HTTP Request Sampler and fill in the fields using the data from the CDP Extension of the certificate. Use the CDP server name from the certificate. We use the GET method because we are fetching data from the server.
2. Add the Listener "Save Responses to a file." It is required to save the received data to a file.
3. Add the View Results Tree to monitor the results and run the script.
As a result, we get the downloaded list of revoked certificates. You can see it in the screenshot above. Now you can increase the number of threads and create a significant load to the CDP.
4. In the example above, the certificate contains several CDP. Therefore, in the test plan, we need to test all of them. But we must address the second CDP only if addressing the first CDP was unsuccessful. You can use the If Controller with the following condition for this:
This means that if the last sample was unsuccessful, part of the script that is inside the controller will be executed. In our case, the part is the second CDP calling. Our script will look like this:
It is also worth noting that LDAP and FTP are sometimes used to distribute CRL. JMeter has samplers for these protocols too - the LDAP Request Sampler and the FTP Request Sampler, which you can use instead if the HTTP Request.
What if we also want to check the validity of our certificate?
5. For this action, we need to use the BeanShell Sampler and the source code from the Apache Software Foundation Subversion Server resource. Extended comments to the code can be found here. You can also download the jar file from there.
We will use a verifyCertificateCRLs method of CRLVerify class to verify the affiliation of our certificate to the CRL. An argument of the method is an object X509Certificate, i.e our certificate.
import com.issart.CRLVerifier; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; import org.bouncycastle.cert.*; inStream = new FileInputStream( "blazemetercom.crt" ); CertificateFactory cf = CertificateFactory. getInstance ( "X.509" ); X509Certificate cert = (X509Certificate)cf. generateCertificate (inStream); CRLVerifier. verifyCertificateCRLs (cert);
After the method call, the CDP address is extracted from the CDP Extension and the certificate is validated. The following URLs are supported: HTTP/S, FTP, LDAP.
The code for BeanShell Sampler is shown below. First, we create an X509Certificate object, and after that set it as the parameter for verifyCertificateCRLs method.
If we have no exceptions, then the CRL is available and the certificate is verified. In other cases, we will get a corresponding error text. Below there is a result of the script. As expected, the CRL is available and the list does not contain the certificate, making it valid.
6. To verify the certificate chain we can use verifyCertificate method of the CertificateVerifier class. In addition to the X509Certificate object, you must also set a list of certificates from the chain as the method parameter. The code for this case is presented below.
Run the script once more. Once again the validation is successful.
In this article, we analyzed the principle of the CRL and also demonstrated validation of the certificate by means of CRL. In conclusion, it is worth noting, that in our case the certificate is used to identify the domain, but also it can be used to identify users in email correspondence or for online business.
It is also worth noting that in this article we explained how a CRL works in the Chrome browser. But in fact, not all modern browsers check CRL, but rather OSCP replaces CRL for revocation checking. For example, browsers that check CRL today are Opera and IE and those that don't check are Chrome and Firefox. OCSP provides real-time revocation information about an individual certificate from an issuing certificate authority. To learn more about load testing OCSP, click here.
Learn advanced JMeter for free from our JMeter Academy.
Published at DZone with permission of Roman Aladev , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.