Showing results for 
Show  only  | Search instead for 
Did you mean: 

What are Your Reasons for Decrypting SSL Traffic?


I need to justify to my clients why I need to decrypt their traffic when monitoring with DCRUM.

Please give me your reasons and how they assisted in your day-to-day monitoring, as well as troubleshooting your client's issues.

Thanks and God bless,



Hello Genesius,

You required a private key to decrypt the traffic in case the certificate is residing on the server because you will not be able to see any operations data and also keep in mind that AMD supports only the RSA Cipher.

SSL decryption can be performed either in the AMD software using OpenSSL or in a hardware SSL accelerator.

  • If SSL decryption is performed in the AMD software, the AMD reads RSA private keys from PEM-encoded disk files during startup.
  • If SSL decryption is performed in a hardware SSL accelerator, the keys may need to be stored in the accelerator card first: after extracting the keys from their servers as PEM-encoded disk files and writing them to the accelerator, the PEM files should be deleted for security reasons.

You can find all your answers from the following link:



@Babar Q.
My query was not "how to", but "why to"?

My fellow DCRUM'ers,
By decrypting SSL traffic, what insights are gained to assist in troubleshooting network application problems?
My clients want to know "why" I need to see inside their secure secured application communications.

Thanks and God bless,

Hello Genesius,

As I mentioned before that you will not be able to see the operations/requests breakdown if the traffic is encrypted. Below is an example where you can see that all the requests breakdown are considered 'Failure' because we didn't install the private key yet for this software service.

One more example for the application's perspective where we do not have private key to decrypt the traffic.

Let me know if it clears the point.



@Babar Q.

I apologize for the miscommunication on my part.

Let's assume my client gives me the private key.
What benefit will they gain from DCRUM being able to view the decrypted payload?

Here is a list of what I have gained from decrypting, but I wanted the opinion from more of my DCRUM peers.

  • Operations (URL’s,
    SQL, etc.)
  • Response times
  • TCP and HTTP errors,
    and their possible root cause(s)
  • Database errors and
  • Operation times

Thanks and God bless,

Hi Genesius,

It's important to know the details. Like you mention, decryption of the payload provides you clarity on all the metrics you mention and more, which is great. However whats the point you may ask... well let me tell you. With this added visibility you're able to see the operations your users are committing and the wait times/errors that come after that. Data on it's own can be quite meaningless, however once you add context that data turns into information and information, specifically in the Digital Performance Management space is power.

For example, say the front end of your application is HTTPS and 50 users access it daily, this application is crucial to your business. One day, 25 of those users complain of slowness and no one knows why. With the private key, DC RUM can see each of those 25 users operations and trend them against the past 5 days to get a good idea of when this issue started. With the private key, DC RUM can provide you the metrics required to help investigate where the slowness is coming from, for example, with the key we can show you that all of the 25 users operation time is spent mostly on the network. With the key we can then show you that all those 25 affected users are connecting over wireless in their office. A ticket can then be raised with the IS team saying that there is an issue with the wireless access point. Without the key, it'll be quite difficult to obtain this level of granularity anywhere else. The private key doesn't just gain insight into metrics you mentioned, it also gives you visibility to further context which is vital in solving issues.

Kind Regards,


Dynatrace Advisor
Dynatrace Advisor

Hi Genesius,

Let's see if I can help to justify the needs of decrypting SSL traffic for monitoring.

First, let's talk about what is there to monitor if we don't decrypt the SSL traffic. You'll still get basic metrics like response time, operation count, TCP errors, user count, transferred bytes, RTT, loss rate... And in 2017 version the SSL decode can even help to depict information such as domain name, cipher suites and TLS version of the encrypted traffic. Sounds good enough for basic monitoring.

So... What about the things we don't see if compared to decrypted SSL traffic? Well, it boils down to mainly one thing: transactional performance. As you already know, we won't be able to see the specific URLs, therefore we won't be able to see the performance for each transaction, plus we won't get to see any 4xx or 5xx response code (because those would have been encrypted). Also we won't see user activity (all we see is a bunch of encrypted data exchange tied to a client IP). All we can do is to monitor the overall performance of the entire tier (for example, the load balancer tier), and at most we can measure the performance of different cipher suites or TLS version being used.

What happens now is that if there is a performance issue, say a user complained about login being slow, we won't be able to gain much visibility from the frontend until we hit the non-SSL part of the application delivery chain. So if there is anything wrong with the LB or web server (assuming SSL is used for this tier as well), we don't really know as the overall performance statistics would have buried the login transactional performance statistic deep within.

Although it is highly suggested to have SSL traffic decrypted for monitoring, it is not mandatory depending on the nature of customer's application environment. So if customer is okay without transactional performance data, or maybe they are complied to use strong cipher suites (DH-related ciphers), then it's all right to forgo this piece. Hope this helps.