Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Burp Collaborator polling service respond with a self-signed certificate (*.polling.myhost.com)

Philippe | Last updated: 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 polling.myhost.com. The polling configuration is as follow.. ``` "ssl": { "certificateFiles" : ["/etc/letsencrypt/archive/polling.myhost.com/privkey1.pem","/etc/letsencrypt/archive/polling.myhost.com/cert1.pem"] } [...] "polling" : { "localAddress" : "64.137.X.X", "publicAddress" : "64.137.X.X", "http": { "port" : 9090 }, "https": { "port" : 9443 }, "ssl": { "hostname" : "polling.myhost.com" } }, ``` The bug I have .. When polling.host.com:9443 is visited, a self-signed certificate *.polling.myhost.com is served. It does not serve the certificate I configured "polling.myhost.com". My understanding was that the interaction events require communication to random sub-domains (a1g2c3.burp.myhost.com). 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. Thanks

PortSwigger Agent | Last updated: Mar 11, 2017 01:45PM UTC

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/polling.myhost.com/privkey1.pem","/etc/letsencrypt/archive/polling.myhost.com/cert1.pem"] } into the polling section, and remove the "hostname" field.

Burp User | Last updated: Mar 15, 2017 07:22PM UTC

[DONE] I have removed the hostname and add the same "certificateFiles" entry. The burp collaborator now respond on "polling.myhost.com:9443" 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 (polling.myhost.com) [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).

PortSwigger Agent | Last updated: Mar 16, 2017 04:39AM UTC