environment/bin/recipes/vnc/notes.md

Here’s what those two pieces typically look like in a QEMU VNC + TLS + SASL setup.

/etc/pki/qemu (TLS x509 creds)

QEMU’s -object tls-creds-x509,...,dir=/etc/pki/qemu,endpoint=server expects this directory to hold the server’s cert/key and the CA it should trust for client certs.

Example layout:

/etc/pki/qemu/
├── ca-cert.pem         # CA cert used to verify client certificates (if verify-peer=yes)
├── server-cert.pem     # Server certificate (CN should match the host, or use subjectAltName)
├── server-key.pem      # Private key for server-cert.pem (chmod 600, root-only)
└── crl.pem             # (optional) Certificate Revocation List

Typical QEMU arg:

-object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes
-vnc :0,tls-creds=tls0,sasl

Notes:

• verify-peer=yes means the VNC client must present a client certificate signed by ca-cert.pem. Omit or set no if you only want encryption without client certs (and rely on SASL for auth).
• File names above are the conventional ones QEMU looks for in that dir in server mode.
• Permissions matter: keep server-key.pem readable only by the QEMU user (e.g., chmod 600).

(If you wanted the client side for certificate auth, you’d create a client bundle with client-cert.pem / client-key.pem and give the server’s CA to the client.)

/etc/sasl2/qemu.conf (SASL settings)

This file tells Cyrus SASL how to authenticate for the “qemu” service. A simple, local-password (sasldb) setup might be:

# /etc/sasl2/qemu.conf
mech_list: scram-sha-256 digest-md5
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/sasldb2

What each line does:

• mech_list: Which SASL mechanisms to allow. (If your build doesn’t have SCRAM, use digest-md5 and/or plain/login — but prefer SCRAM or DIGEST over PLAIN.)
• pwcheck_method: auxprop + auxprop_plugin: sasldb: use the local SASL database.
• sasldb_path: where the password DB lives (default is /etc/sasldb2 on many distros).

Create users in the sasldb:

sudo saslpasswd2 -a qemu -c alice
# (it will prompt for a password)
sudo sasldblistusers2 -f /etc/sasldb2    # verify entry exists

Then run QEMU with both TLS and SASL:

qemu-system-x86_64 \
  -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=no \
  -vnc :0,tls-creds=tls0,sasl

• Client connects over TLS (encrypted), then is prompted for SASL username/password (“alice” and the password you set).
• If you set verify-peer=yes, the client must also present a valid client cert signed by your CA.

Quick OpenSSL one-liners (for testing)

For production, use a proper CA workflow and strong key handling.

# CA
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca-cert.pem -subj "/CN=QEMU Test CA"

# Server cert
openssl genrsa -out server-key.pem 2048
openssl req -new -key server-key.pem -out server.csr -subj "/CN=your.host.name"
openssl x509 -req -in server.csr -CA ca-cert.pem -CAkey ca.key -CAcreateserial -out server-cert.pem -days 825 -sha256
install -m 600 server-key.pem /etc/pki/qemu/
install -m 644 server-cert.pem ca-cert.pem /etc/pki/qemu/

Common pitfalls

• Wrong filenames/paths in /etc/pki/qemu → QEMU won’t find the certs.
• Permissions too open on server-key.pem → QEMU may refuse or it’s a security risk.
• SASL mechanism mismatch → ensure your client supports one from mech_list.
• No TLS but SASL with PLAIN/LOGIN → credentials go over the wire unencrypted; always pair PLAIN/LOGIN with TLS.

If you tell me your distro, I can tailor the exact package names (Cyrus SASL modules) and service paths.