So switched to using dynamic DNS through 'NameCheap' on a domain I own.īe aware that lego needs to be able to open port 443, so if you already have a web server listening for SSL connections, you will need to stop it during renewal or switch to file validation. You could use Task Scheduler to automatically run a batch file once a month to renew and restart Murmur.īe aware that Let's Encrypt has a cap on certificates and renewals per domain, which prevented me from using my free dynamic DNS by. The new certificate won't be loaded until Murmur is restarted. Restarted Murmur, right clicked the tray icon and used 'Show Log' to check for errors, connected to the server with the client and used 'Server, Information, View Certificate'.Īfter 90 days the certificate will need to be renewed and that also requires validation again, same command as before, but replace 'run' with 'renew'. SslKey=C:\\insert-your-lego-path\\.lego\\certificates\\ SslCert=C:\\insert-your-lego-path\\.lego\\certificates\\ lego/certificates sub folder.Įdited 'C:\Program Files (x86)\Mumble\murmur.ini', uncommented and set the paths WITH DOUBLE BACKSLASHES: A list of the certificates that you have purchased from us will now be visible. Lego -email=" -domains="" -exclude "http-01" runĬhecked that a. To get started, login to the SSL.com User Portal and click the Orders tab. In my router settings, forwarded port 443 to my local server for validation by TLS-SNI-01. Downloaded and extracted 'lego_windows_amd64.zip' from:.As there was no official Windows client, found a great alternative at:.Thanks for the info, I managed to do the same thing for a home Windows server. So this file contains your server certificate, AS WELL AS the certificates of the certification authority and all intermediary certificates needed to establish the chain of trust. This is concatenation of cert.pem and chain.pem. SslKey=/etc/letsencrypt/live//privkey.pemĪll certificates, including server certificate. I have been working hard at this for the last day or so and am not getting what I need. SslCA=/etc/letsencrypt/live/$domain/fullchain.pem (/fullchain.pem My boss has tasked me with building a script to renew the computer certificate on all the workstations in the company as RSA SHA512 certificates using the existing keys on the certificates on the workstations. SslKey=/etc/letsencrypt/live/$domain/privkey.pem You can make sure there are not any issues by checking the mumble-server log: sudo tail -f /var/log/mumble-server/mumble-server.log Note that if you have a long-running mumble server, you will need to restart the server in order to grab new certificates once they expire. I think that might be the better solution.SslCert=/etc/letsencrypt/live/$domain/cert.pem Restart the mumble-server and the certificate should be handled. and not any intermediates in that persons keychain or other certificate stores. This verification would only use the certificates in the. But I'm not sure it'd do much good for anyone else.Īn alternative to this, would be to have the Certificate Wizard verify the client certificate chain and show a good/bad indicator in the Wizard. That would at least give people who are familiar with the terms "certificate chain" and "intermediate certificate" a chance to act. Please include all intermediate certificates and try again.". I think that should satisfy the request, but we'd still be using SSL-speak to convey the error message to the user: "Your client's certificate chain is not complete. We could then potentially walk the chain and check for the specific case of missing intermediate certificates. If the server tells the client that SSL Error: The root CA certificate is not trusted for this purpose, the server must be complaining about the client's certificate chain. We should probably make it clearer, if possible. It is thus missing some details like original creator etc. ![]() This ticket has been migrated from sourceforge. I can attach the public certificates if needed. I found this rather odd as it is signed by the same CA as defined in mumble-server.ini (sslCA). My certificate in question is signed by my own CA, which would explain the trust issue with the server. SSL Error: The root CA certificate is not trusted for this purpose Having looked at the server log for my private team's server I found this: I would consider it a bug that an issue with the client certificate is not told to the user for the reason that the connection failed. I generated a fresh one within Mumble and I could connect to servers. Every connection attempt was immediately dropped with "Server connection failed: The remote host closed the connection.".ĭireFog suggested it may be a certificate issue. Maybe this is the same certificate that Varnish on www is complaining about. At there is a different certificate than That one expired yesterday. I was unable to connect to any Mumble server (including my private team one). The certificate presented to my browser for is actually fine, but apparently the backend is serving an expired certificate to Varnish.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |