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:

```bash
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:

```bash
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.

```bash
# 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.