I have a letsencrypt.org certificate and have been using it for my web server’s SSL for a few years with no problems. Just now, I was trying to use the same cert with the python ssl package in order to create a small ssl web server for a special purpose (talking with a SONOFF device, in case you’re interested). If I create my own self-signed cert, the server runs just fine (but since it’s self-signed, the SONOFF device refuses to connect). When I grab the letsencrypt cert.pem and key.pem files and try to use those instead, the python ssl library is now asking for a PEM pass phase! My understanding is that letsencrypt certs don’t have a pass phrase, so I’m not sure why it’s asking or what answer to give.
I’m actually making use of Seven Watt’s git library code here: https://github.com/SevenW/httpwebsockethandler
and the relevant part is simply opening a socket at 8080 and then wrapping it inside SSL. If you look at his “ExampleWSServer.py”, you’ll see that I made only a minor addition to the “wrap_socket” call.
When I run this using my own self-signed cert, it doesn’t ask for a password, but the SONOFF device also doesn’t connect. (I’ve read that others have found that the latest SONOFF firmware seems to require an actual legit cert for the SSL, whereas the previous versions of the firmware didn’t care.)
(I apologize but I can’t seem to find a way to force this interface to allow me indent things properly. Suffice it to say, the only change I made was on the line where it calls “wrap_socket”, so probably it’s best to look at the example version from the git page: https://github.com/SevenW/httpwebsockethandler/blob/master/ExampleWSServer.py
)
def _ws_main():
try: #Replace WSSimpleEcho with your own subclass of HTTPWebSocketHandler
server = ThreadedHTTPServer((’’, port), WSSimpleEcho)
server.daemon_threads = True
server.auth = b64encode(credentials)
if secure:
server.auth = b64encode(credentials)
server.socket = ssl.wrap_socket (server.socket, certfile=’./cert.pem’, keyfile=’./key.pem’, server_side=True)
print(‘started secure https server at port %d’ % (port,))
else:
print(‘started http server at port %d’ % (port,))
server.serve_forever()
except KeyboardInterrupt:
print(’^C received, shutting down server’)
server.socket.close()
I was able to run that ExampleWSServer, with the modified wrap_socket call, using a certiifcate (fullchain.pem rather than cert.pem) and key from Certbot, without any issues.
Perhaps to clarify: passphrases are attached to the private key, not to the certificate. It is an entirely client-side decision whether a key is encrypted or not, Let’s Encrypt doesn’t know about it. If it is asking you for a passphrase, then it means you probably created the key with a passphrase, or added one at some stage.
All of the “key” files I have, which includes ones from letsencrypt.org, all have the extra “Proc-Type” and “DEK-Info” lines you show. If this implies that the letsencrypt key I have requires a password, I don’t know what the password would be, especially since from what I read they’re not supposed to have a password.
I’m intrigued by the idea farther above of using the “fullchain.pem”. I tried that and it still asked for a password. Using the “openssl” command mentioned also asked for a password.
I admit to not knowing a lot about certs or how they’re supposed to be used by wrap_socket. I just don’t understand why a letsencrypt cert, which is not supposed to have a password, seems to require a password, and given that it does, I don’t know what that password would be.
I appreciate everyone’s help. Maybe I should send a note to letsencrypt’s help email address? I’m out of options.
It may be a good time to step back and review the process. This will help you understand what component each part plays.
A) Let’s Encrypt does not generate Private Keys. These are generated from a program called a client
B) A private key is used to generate a CSR (which is a syntax) which tells let’s encrypt what domains the certificate should protect
C) Once Let’s Encrypt knows what domains (by parsing the csr) it will create challenges (so you can prove that you own those domains)
D) Let’s encrypt will then generate the certificates if the challenges are asnwered
Key takeways
A) Private key generated is matched to the certificate
B) The default client (certbot) does NOT encrypt private keys generated
C) The reason why your self signed certificates are working is most likely that the private keys aren’t encrypted
D) You can reproduce the error with self signed certificates by adding -des to your private key generation command
The path of lest resistance is most likekly to issue new certificates with new private keys and move from the client you are using to something like certbot
Ok, I think I see what was happening. It looks as though when I “install” the letsencrypt .pem files using Apple’s Server application, it actually puts a pass phrase into that stored version. If I, instead, go to the /etc/letsencrypt directory and look under there for the original .pem files which I received from letsencrypt, then I see files which do not have a password.
I copied and used these non-password files and that runs without asking for a password (of course!)
Thanks, everyone, for hanging in there with me! I think this should take care of my issues! Now, I just need to go back to my sonoff device and see if using the letsencrypt originated cert, on the actual host to which it’s issued, will make it establish the SSL connection correctly. (Of course, I’ll have to use the outside IP address for the server and forward port 8080 through the NAT, at least in order to test it initially.)
