-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What files are given to Syncplay for TLS when acme.sh is used instead of certbot? #250
Comments
I haven't used acme. The only guidance we have is https://github.com/Syncplay/syncplay/wiki/TLS-support |
The furtherst I got was:
Which results to:
If I replace |
Did you check if the |
Looking through readme at https://github.com/Neilpang/acme.sh/blob/master/README.md#3-install-the-cert-to-apachenginx-etc there is explanation how to install certificates with formats and paths similar to what Syncplay expects. At very least this should be a serviceable workaround. Personally I'm thinking that some way of specifying arbitrary names for PEM files in Syncplay might be worth exploring after all. |
I should read documentations better. However even with those instructions, Syncplay stays unhappy. My script now says: DOMAINNAME=relpda.mikaela.info
/root/.acme.sh/acme.sh --install-cert -d $DOMAINNAME --cert-file /opt/syncplay/ssl/cert.pem --key-file /opt/syncplay/ssl/privkey.pem --fullchain-file /opt/syncplay/ssl/chain.pem --reloadcmd "systemctl restart syncplay-server --quiet" It outputs me:
The directory looks like this:
and Syncplay tells me:
I have git pulled both client and server to 0f284e7. |
Running the following command should give detailed info about what exactly is going on: Edit: from the looks of it y.relpda.mikaela.info you connect to is a different domain name than relpda.mikaela.info your certificate is for. Maybe the problem is here? |
I changed the command to The certificate is valid for relpda.mikaela.info, ds.relpda.mikaela.info, nat.relpda.mikaela.info, y.relpda.mikaela.info. relpda.mikaela.info is the main domain, but it's IPv6-only, so I also have ds. and nat., y. is for Yggdrasil and requires special software for accessing, and I don't have this issue with Mumble or ZNC connected to the same domain. I also have another Mumble user whom I think to connect to ds.relpda.mikaela.info. |
I tried connecting directly to relpda.mikaela.info:14404 without anything being different. Are you on freenode or something else where I could give you the password in case you can see something more useful? |
On IRC @daniel-123 figured that I was passing the wrong arguments to acme.sh. My script now says:
expanded:
The issue was that Syncplay expected acme.sh's |
I tend to agree with you, but I believe this is just not feasible in our CLI-based current configuration system. I am in favor of @alxpettit idea of using a config file (perhaps an INI file) for our server in the future. |
Some other application use --key --cert --ca arguments to pass the path directly ? |
Thanks for your work in helping us understand these issues. We are trying to avoid further complicating the Syncplay codebase, especially when it comes to TLS-related features. As such, while we will link to this issue from https://syncplay.pl/guide/server/ so that those with similar issues can understand what is happening, no changes to the Syncplay code are currently anticipated. In the future more information on this topic might be integrated into the guide at: https://github.com/Syncplay/syncplay/wiki/TLS-support at which point the reference to this issue could become redundant. |
Hello, I am using Lego for requesting certificates from Let's Encrypt.
I tried:
All combinations result in the server printing "TLS support is enabled." and in the client printing "Secure connection failed. The server uses an invalid security certificate. This communication could be intercepted by a third party. For further details and troubleshooting see here." - unfortunately neither of these messages indicate what the issue is. Of course, my certificate is valid (not expired, matching SAN and trusted by the client system's root CA store). Trying to connect using OpenSSL makes it seem like there is no TLS certificate being sent at all:
If I put Syncplay behind Would appreciate any input. |
@tacerus Hopefully you will find https://github.com/Syncplay/syncplay/wiki/TLS-support of assistance. |
Also be aware that if you are connecting to yourself as localhost then that might cause the TLS to fail. Test with a remote connection. |
Thanks for your reply! I checked the article you linked, and attempted one more combination:
Unfortunately it did not change the behavior of the program either. Of course, I am connecting using the external domain name which is included in the SAN's of the certificate. |
Even if connecting to the external domain, if you are connecting to yourself then there can be problems because your router might end up just making it a loopback which then means it has the wrong IP to the external one and fails, but this isn't my specialty so I could be wrong. If you are connecting via a loopback then you shouldn't need TLS. You ideally want someone who is on a completely different network to the server to connect to your server for testing purpose. |
This is over the internet, so TLS is necessary. As said, if I proxy it through a separate application like |
@tacerus Exact files and their contents that Syncplay expects are the same as old certbot produces by default:
In case of current Let's Encrypt certificates, the intermediate certificate will be the |
Thank you very much for the insight, @daniel-123! |
With certbot I just copied all files and pointed Syncplay to the directory, but acme.sh gives me a separate set of files.
README cert.pem chain.pem fullchain.pem privkey.pem
ca.cer relpda.mikaela.info.cer relpda.mikaela.info.csr relpda.mikaela.info.key fullchain.cer relpda.mikaela.info.conf relpda.mikaela.info.csr.conf
Which of them do I give to Syncplay and will it understand them directly or do I have to rename them?
The text was updated successfully, but these errors were encountered: