The certificate instructions could still be better
See original GitHub issueHello! First of all, thanks for this project. 😄
I had a little trouble getting it to work at first and I couldn’t figure out why the browser was part of the process. It eventually dawned on me that most people on Linux will be using Scratch 3 through the browser. I had downloaded the Electron Linux binary zip and extracted the Scratch 3 resources directory from the Windows installer. Try it if you haven’t, it’s dead easy and it works really well.
The quick and dirty way to make the desktop app work is to pass the --ignore-certificate-errors
option to the electron
binary. That’s quite nasty though and I thought I could do better.
If we’re shooting for a truly trusted certificate here then we need a longer expiry time. Let’s say 10 years, so that’s -days 3650
.
Rather than use names like localhost
and scratch-device-manager
, we need the name to match what’s actually being requested so use device-manager.scratch.mit.edu
everywhere.
The -subj
option can be dropped if you set prompt = no
in the config and then you only need to specify the CN once.
Was the keyUsage=digitalSignature\nextendedKeyUsage=serverAuth
part added for any particular reason? I found that OpenSSL fails to trust the certificate with this in place. I didn’t test whether it impacts NSS (used by Firefox, Chrome, Electron) in the end but it works fine without.
The printf
bit looks a bit clunky. We can use a here string instead like this:
-config /dev/stdin <<< $'[dn]\nCN=device-manager.scratch.mit.edu\n[req]\nprompt = no\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:device-manager.scratch.mit.edu'
I have no idea what the openssl pkcs12
part is supposed to be for. scratch-device-manager.pfx
doesn’t appear to be used for anything and I got this working without it.
Similarly, the grep | tr
part is bizarre. cat
will do the same job as grep -h ^
and OpenSSL doesn’t write Windows-style line endings so the tr
isn’t needed. This could simply be:
cat scratch-device-manager.cer scratch-device-manager.key > scratch-device-manager.pem
Alternatively, why not just skip that step entirely and have Python read the certificate and key from separate files like this?
cert = pathlib.Path(__file__).with_name("scratch-device-manager.key")
key = pathlib.Path(__file__).with_name("scratch-device-manager.cer")
ssl_context.load_cert_chain(cert, key)
So to sum up, the one and only command you need for generating the key and certificate is:
openssl req -x509 -out scratch-device-manager.cer -keyout scratch-device-manager.key -newkey rsa:2048 -nodes -sha256 -days 3650 -extensions EXT -config /dev/stdin <<< $'[dn]\nCN=device-manager.scratch.mit.edu\n[req]\nprompt = no\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:device-manager.scratch.mit.edu'
Getting regular browsers to trust scratch-device-manager.cer
is easy enough. Firefox, Chrome, and friends allow you to import trusted certificates through the UI but what about the desktop app? By default, Electron uses the same user-wide trust store as Chrome in ~/.pki/nssdb
so if you import it into Chrome then Electron will see it too. What if you don’t have Chrome? You can use the certutil
tool from NSS to do it from the command line.
certutil -A -d sql:~/.pki/nssdb -n "Scratch Device Manager" -t CT,, -i scratch-device-manager.crt
So hopefully we can stop telling users to do thisisunsafe
and the like now. There is a way to get Firefox, Chrome, and Electron all to use the same system-wide trust store. This could be useful for school environments but it’s a little outside the scope of these instructions. Ask me if you’re interested.
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (7 by maintainers)
@chewi Thanks for the comment. I learned again about bash word splitting. I removed quotations from [[ ]] conditionals.
I also did another testing with Ubuntu based Elementary OS system and did some fix up (certutil -d option needed ‘sql’ prefix with Ubuntu system). Now the changes are in the master branch.
Now I think this work is done.
@chewi Thanks a lot for this feedback. Yeah, that certificate handling work is rough one and needs improvement. Your comments are really helpful to improve and reduce user confusions. Let me have some more time to digest them and do some testing. Thanks again!