Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Burp Collaborator polling service respond with a self-signed certificate (*

Philippe Arteau Mar 10, 2017 10:07PM UTC

I am using a certificate generated with Let's Encrypt.

The certificate is matching the domain expected for the polling communication. Let's say

The polling configuration is as follow..
"ssl": {
"certificateFiles" : ["/etc/letsencrypt/archive/","/etc/letsencrypt/archive/"]

"polling" : {
"localAddress" : "64.137.X.X",
"publicAddress" : "64.137.X.X",
"http": {
"port" : 9090
"https": {
"port" : 9443
"ssl": {
"hostname" : ""

The bug I have .. When is visited, a self-signed certificate * is served. It does not serve the certificate I configured "".

My understanding was that the interaction events require communication to random sub-domains ( On the other hand, the polling communication would only need one specific host.
Maybe, I don't understand the requirement for a wildcard on the polling address.


Dafydd Stuttard Mar 11, 2017 01:47PM UTC Support Center agent

The SSL configuration you have in the “polling” section is telling the Collaborator server to create a self-signed certificate.

Try copying the SSL configuration that you have earlier in your config file:

“ssl”: {
“certificateFiles” : [“/etc/letsencrypt/archive/”,“/etc/letsencrypt/archive/”]

into the polling section, and remove the “hostname” field.

Philippe Arteau Mar 15, 2017 07:22PM UTC
[DONE] I have removed the hostname and add the same "certificateFiles" entry.

The burp collaborator now respond on "" with the valid certificate.
In Chrome, the communication shows up as "Secure".

I sniff the communication on my burp collaborator instance.
[OK] I was able to see that Burp client did connect to right port (9443)
[OK] It was using TLS protocol
[OK] The right hostname is used (
[ERR] The Burp client is sending the alert message "Certificate Unknown" (02 2E)

This intrigue me. Why is burp not recognizing this cert while Chrome see it as valid?

My first thought was that I must be pointing to an old JVM and therefore an outdated truststore was being used. I realize Burp was using its own instance of Java.

I opened the keystore [1] and could not find any of the intermediate CA that signed my certificate [2]. I added "Let's Encrypt" to the truststore. The Health Check passed 100%.

[1] C:\program files\burpsuitepro\jre\lib\security\cacerts
[2] (Let's Encrypt Authority X3 ::: effective=17/Mar/2016 ::: expire=17/Mar/2021)

I think the Java truststore is out of date since its date on the file system was march 6th 2016 and the CA certificate was create 11 days later (March 17th 2016).

Dafydd Stuttard Mar 16, 2017 09:06AM UTC Support Center agent

Ok, this sounds like the Java trust store doesn’t include the relevant CA cert for your provider. If manually installing the certificate got everything working, then it sounds like you’re good to go.

Post Your public answer

Your name
Your email address