search

Stieneee / mumble-discord-bridge

A simple voice bridge between Mumble and Discord.
MIT License
149 stars 16 forks source link

Bot refuses to connect to self-signed server, even with MUMBLE_INSECURE flag #25

Closed Swizzler121 closed 2 years ago

Swizzler121 commented 2 years ago

Attempting to connect to self-signed server returns error:

2021/11/03 15:37:11 x509: cannot validate certificate for 192.168.1.xxx because it doesn't contain any IP SANs

Current docker run command:

sudo docker run -e MUMBLE_ADDRESS=192.168.1.xxx -e DISCORD_TOKEN=xxx -e DISCORD_GID=xxx -e DISCORD_CID=xxx -e MUMBLE_INSECURE --restart=always --name=mumble-discord-bridge -d stieneee/mumble-discord-bridge

can't make a valid cert because it's running on a local network...

stryan commented 2 years ago

MUMBLE_INSECURE only tells the bridge to not verify the certificate. It does still require the certificate name and the remote hostname (in this case the IP address) to match, as per this StackOverflow post

Self-signed certs with IP addresses should be allowed, but you do need to list the IP address as a subjectAltName in the cert otherwise it's an improperly created certificate.

Swizzler121 commented 2 years ago

Do you know where murmur sticks the certificate it generates? I've been googling but haven't found anything, and don't want to waste time setting up everything for generating a certificate that i'm not using

Swizzler121 commented 2 years ago

Also as a suggestion in the future, couldn't you also just implement InsecureSkipVerify as an optional flag? Seems like that would solve the problem without making the user go through all these hoops. It's a mumble server I'm going to be running for a couple hours for the people that don't have discord, not a bank.

stryan commented 2 years ago

I'm not sure off the top of my head; I think it might store it in whatever database you have set up for Murmur (sqlite by default).

I may have misread your initial comment though; in the docker command you're providing, have you tried setting "-e MUMBLE_INSECURE" to be "-e MUMBLE_INSECURE=true"? I don't think docker autosets environment variables to true.

As for setting it by default, I'm not the dev (just a contributor) but I'm pretty sure this situation only occurs when using a self-generated certificate that isn't properly created i.e. you have gone out of your way to not use the Murmur generated cert.

Swizzler121 commented 2 years ago

I am using the murmur generated cert, Yes adding =true to the end of MUMBLE-INSECURE fixed the issue. I would add that to your readme, because i got the impression since it didn't have "string" after it, simply calling the flag in the command triggered it

stryan commented 2 years ago

Curious then, I guess Murmur doesn't follow the spec and have the IP address as a subjectAltName. I'd recommend just using hostnames with a private TLD (so .lan or .home) in the future though; I wouldn't be surprised if other thing break on certs for IP addresses without the IP listed as a SAN.

But sure, I'll send a PR to update the readme.

Swizzler121 commented 2 years ago

Thanks for the help so soon, I was trying to set this up for a last minute party this evening, so you saved the day. I had tried adding =yes to the command earlier, but never thought to try =true.

stryan commented 2 years ago

No problem, the readme was definitely a bit unclear there. Glad it's working now. (and fortunately the initial issue came in while I was on an early lunch break :) ).