Closed totaam closed 1 month ago
The only downside is that in my experience, mkcert is easier to manage - at least for local testing.
Package a go dependency? šš¤£
Package a go dependency? šš¤£
No chance, but depending on a mkcert
package wouldn't be too bad. Except there isn't one for RPM, so that's a non-starter.
It would be neat if we could use this to generate a SSL certificate + key on a remote host and install the certificate on the local system.
Without https://github.com/FiloSottile/mkcert, I think you will be re-inventing the wheel š
... especially if you would somehow expect that the package lands on LTSs of all of the OSes you support by "not your actions"
Without https://github.com/FiloSottile/mkcert, I think you will be re-inventing the wheel š
No, for the python client, all the plumbing is already in place for accepting certificates, even the GUI: #3305, #3299
For the html5 client, things are going to be more complicated no matter what - because browsers.
Invoking mkcert
if installed is an option, and showing a warning if it's not.
Mostly done.
Tested certificate download for localhost:
rm -fr $HOME/.config/xpra/ssl
xpra setup-ssl ssh://localhost/
Connected (version 2.0, client OpenSSH_9.6)
Authentication (publickey) successful!
ssh server OS is 'linux-gnu'
paramiko SSH agent forwarding enabled
SSH: "SSL certificate file '/etc/xpra/ssl/key.pem' is not accessible"
SSH: 'generating a new SSL certificate:'
SSH: " '/home/antoine/.config/xpra/ssl/key.pem'"
SSH: " '/home/antoine/.config/xpra/ssl/cert.pem'"
SSH: '...........+......+..+...+..........+..+....+.....+......+.......+...+...+.....+.+...+...........+......+.........+++++++++++++++++++++++++++++++++++++++++++++*..+.+..+...+.......+....................+...+..................+.+++++++++++++++++++++++++++++++++++++++++++++*.............+..+...+...............+.+........+.......+.....+.+..+...+..........+..+.............+...............+....................+...+..........+............+...............+..+.+..+....+........+.......+.....+......+.......+...+...+......+...+........+....+...............+......+..+.+.....+.+..............+......+.............+...+...+.....+....+..+.+.................................+.....+.+.........+.................+.........+.+........+.+....................+....+++++'
SSH: '...+.....+...+...+..........+++++++++++++++++++++++++++++++++++++++++++++*.+...+.+...+..+......+....+.....+......+...+......+.+...+.........+......+......+.........+.........+...+..................+....................+.+......+............+...+..+...+.......+.....+.+..+....+...+........+...+.....................+.+.........+...+...+..+++++++++++++++++++++++++++++++++++++++++++++*....+........+....+..+......+.........+.........+.......+..............+....+.....+..........+......+......+.....+....+.........+..+.............+..+...............+............+.......+..............+..........+...........+.........+....+........+...+..............................+.+...........+.......+...+..+.+..............+.......+......+.....+....+...+..+.+........+................+.....+...+.+......+...+......+.....+.........+............+.+..+++++'
SSH: '-----'
SSH EOF on stderr of run-xpra
saved SSL certificate to '/home/antoine/.config/xpra/ssl/hosts/localhost/cert.pem'
The certificate has been generated:
$ ls $HOME/.config/xpra/ssl/
cert.pem hosts key.pem ssl-cert.pem
And this is the same one we now have in the local store for localhost
:
cmp $HOME/.config/xpra/ssl/cert.pem $HOME/.config/xpra/ssl/hosts/localhost/cert.pem
$ echo $?
0
Which means that ssl connections to this host:
xpra start --start=xterm --bind-tcp=0.0.0.0:10000 --no-daemon -d ssl --ssl-cert=auto
should succeed without warnings - and they do!
$ xpra id ssl://localhost:10000/
TLS_AES_256_GCM_SHA384, 256 bits
SSL handshake complete, TLSv1.3
TLS_AES_256_GCM_SHA384, 256 bits
display=:1
machine-id=ecb83875ba224e1396fe7c0a6a0b82c7
pid=210859
platform=linux
session-name=xterm
session-type=seamless
uuid=a1a58f104434463ab81e391b02503a37
Suggested in https://github.com/orgs/Xpra-org/discussions/4146#discussioncomment-9975850
This subcommand can be called by the post-installation scripts, simplifying:
Could be very useful for WebTransport - if we can figure out how to make the browsers accept the certificates: https://github.com/Xpra-org/xpra-html5/issues/143#issuecomment-2183972669
The only downside is that in my experience, mkcert is easier to manage - at least for local testing.
We already have #3299 for accepting certificates per-host in the Python client. Perhaps this could be enhanced too: qrencode the certificate hash for easier verification?
It would be neat if we could use this to generate a SSL certificate + key on a remote host and install the certificate on the local system. Something like: