new subcommand to generate SSL certificates easily

[totaam]

Suggested in https://github.com/orgs/Xpra-org/discussions/4146#discussioncomment-9975850

This subcommand can be called by the post-installation scripts, simplifying:

• xpra/packaging/MSWindows/xpra.iss

  Lines 188 to 195 in d23f941

  	config := ExpandConstant('{app}\etc\ssl\openssl.cnf');
  	args := 'req -new -newkey rsa:4096 -days 365 -nodes -x509 -config "'+config+'" -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=localhost" -out "'+cert+'" -keyout "'+cert+'"';
  	openssl := ExpandConstant('{app}\OpenSSL.exe');
  	if (FileExists(openssl)) then
  	begin
  	Log('PostInstall() generating ssl-cert.pem');
  	Exec(openssl, args, '', SW_HIDE, ewWaitUntilTerminated, ResultCode);
  	end;

• xpra/packaging/debian/xpra/xpra-server.postinst

  Lines 16 to 18 in d23f941

  	openssl req -new -newkey rsa:4096 -days 3650 -nodes -x509 \
  	-subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=localhost" \
  	-keyout "/etc/xpra/key.pem" -out "/etc/xpra/cert.pem"

• xpra/packaging/rpm/xpra.spec

  Lines 770 to 772 in d23f941

  	openssl req -new -newkey rsa:4096 -days 3650 -nodes -x509 \
  	-subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=localhost" \
  	-keyout "/etc/xpra/key.pem" -out "/etc/xpra/cert.pem" 2> /dev/null

  
  (and fixing the MS Windows one which is currently broken: https://github.com/orgs/Xpra-org/discussions/4146#discussioncomment-9974587)

Could be very useful for WebTransport - if we can figure out how to make the browsers accept the certificates: Xpra-org/xpra-html5#143 (comment)

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:

xpra setup-ssl ssh://host/

[stdedos]

The only downside is that in my experience, mkcert is easier to manage - at least for local testing.

Package a go dependency? 😝🤣

[totaam]

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.

[stdedos]

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"

[totaam]

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.

[totaam]

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