This is a read-only archive of the Mumble forums.

This website archives and makes accessible historical state. It receives no updates or corrections. It is provided only to keep the information accessible as-is, under their old address.

For up-to-date information please refer to the Mumble website and its linked documentation and other resources. For support please refer to one of our other community/support channels.

Jump to content

Comodo SSL prevents any connection


Penguin120
 Share

Recommended Posts

Hello,

A long time ago (March 2015), I created a Comodo SSL certificate to use with Mumble, following the instructions here: http://wiki.mumble.info/wiki/Obtaining_a_Comodo_Certificate For a long time everything worked and it was puppies and kittens and rainbows.


Then last week I stopped being able to connect to any Mumble server at all, even random ones from the Public Internet section of the Connection window. The message was always "Server connection failed: The remote host closed the connection." I could see the server user counts and ping in the connection window, but could not connect. It magically started working again after a few frustrating hours of rebooting routers and reinstalling, but I never figured out what the cause was, my functional setup when it was working was identical to when it wasn't. It worked for the rest of the week until today.


The issue is happening again, and this time I was able to get a Wireshark trace running, which looked like this for every server (this one happened to be a private one, so IP is blocked):

http://i.imgur.com/n4vQMBu.png


The grey block at the top is the initial connection, then the white section are the client sending the SSL connection info, I can see strings from the certificate in the data sections. Then the red block at the end is the server sending a whole pile of "RESET" packets, terminating the connection. I don't have access to the server logs, so I don't know why it chose to reset the connection. Again, this happens on ALL servers that I try, public or private.


If I go and use the Certificate Wizard and replace the Comodo SSL certificate with a self-signed certificate from the client, everything works again with no other changes. Just taking the three clicks and 5 seconds to swap certs. The Wireshark using the self-signed certificate and connecting to the same server as above looks like this:

http://i.imgur.com/1RhW1oP.png


That's the entire connection process from opening the connection window, selecting the server, and hitting connect. I stopped the trace when I was loaded into the lobby. You can see the massive difference, and the only state change to the entire process was swapping the Comodo certificate for the self-signed certificate.


Now I did check, and the Comodo cert that I'm using is good until April 2016. I used their recovery tool to generate a new copy of the same certificate, followed the directions on the help page to reload it, and had the same problem. I used a new email address to generate a brand-new Comodo cert, never used before for anything, and had the same problem. Every time, the self-signed one just works and the Comodo cert shits the bed on every single connection.


I checked my computer's Trusted Root Certification Authorities and there are no "localhost" phantom certificates (as I saw mentioned in an older help thread), nor has Skype ever been installed on this machine (also seen on an older help thread).


Help!

Link to comment
Share on other sites

  • Administrators

I do not know why it sometimes works and sometimes doesn't.


One thing you might want to look into is whether you have all required intermediate certificates loaded into Mumble.


When it does work, and you look at your own user info, can you see the whole certificate chain?


...Not that that should prevent the connection in the first place. But I don't know what else to suggest right now. Why doesn't your Wireshark show the individual messages of the TLS handshake, BTW? That's probably help in troubleshooting.

Link to comment
Share on other sites

I do not know why it sometimes works and sometimes doesn't.


One thing you might want to look into is whether you have all required intermediate certificates loaded into Mumble.

 

I don't know how I would check that.

 

...Not that that should prevent the connection in the first place. But I don't know what else to suggest right now. Why doesn't your Wireshark show the individual messages of the TLS handshake, BTW? That's probably help in troubleshooting.

 

How do I get it to show the whole thing? I can send you the capture file if it would help.

Link to comment
Share on other sites

  • 2 weeks later...
  • Administrators

When you're successfully able to use the Comodo certificate with Mumble, and you're connected to a server, try the following:


- Right click your name in the user view.

- Choose User Information.

- In the User Information dialog, there's a button to view your certificate.


In the certificate viewer, there are two sections.


The top section is a list of certificates in the chain. You can select the certificates, and the bottom pane shows you the information for the selected certificate.


What your certificate chain should look like is:


Your certificate should be in there.

When you select your certificate, it should show you an issuer name.


A certificate with that issuer name should also be in the certificate list (top section).


That would be an intermediate certificate.

The intermediate certificate, if it is in there, would presumably have (one of?) the Comodo root certificate(s) as its issuer.


The root does not need to be in the list, as that is provided by your system, if your system trusts the given root certificate.


If the intermediate certificate is not there, not all systems will be able to verify it. (But, Windows servers, as an example, should, because Windows will automatically finish an unfinished certificate chain.)


Another thing you could look at is whether your certificate was issued as a SHA1 or SHA256 certificate.

If it is not SHA1, it could potentially be incompatible with a quite few servers out there.

Link to comment
Share on other sites

 Share

×
×
  • Create New...