Integrate go-p11-kit into Pelican and use it to sign TLS connection

[h2zh]

Update: Rewrote this PR description so it now walks through how Pelican and XRootD work together to deliver full PKCS#11-based TLS signing end to end.

This PR wires XRootD’s OpenSSL TLS layer into Pelican’s PKCS#11 helper so the TLS private key never has to be read by the xrootd process. Instead, every TLS signature goes through a PKCS#11 URI backed by go-p11-kit.

Highlights

• The private key never leaves Pelican process. Only “sign this” requests and resulting signatures traverse the socket.
• OpenSSL reads only the certificate chain from -cert; the key is referenced via the pkcs11: URI.
• By default, the value of Server_EnablePKCS11 is set to false because this feature is under development. But when this feature is enabled in prod, I plan to switch the default to true to enforce this security enhancement.

param.Server_EnablePKCS11.GetBool() means if the server admin intends to enable PKCS11
pkcs11Info.Enabled represents if PKCS11 is really enabled in Pelican (e.g. it could be disabled during runtime due to the lack of dependency)

Technical details

1. Client opens TCP to xrootd exactly as before.
2. XRootD’s OpenSSL context loads only the certificate; but the key path is a PKCS#11 URI (pkcs11:token=pelican-tls;object=server-key;type=private).
3. When OpenSSL needs to sign, the pkcs11 engine (libengine-pkcs11-openssl + libp11) looks up PKCS11_MODULE_PATH (= /usr/lib64/pkcs11/p11-kit-client.so) and connects to the p11-kit RPC socket provided by Pelican via P11_KIT_SERVER_ADDRESS.
4. Pelican’s p11proxy goroutine accepts that connection, exposes the in-memory key via go-p11-kit, and fulfils the C_Sign request with the real TLS key (which never leaves Pelican’s process memory).

How to test

Rebuild XRootD with this counterpart PR in pelicanplatform/xrood repo: PelicanPlatform/xrootd#42

Install necessary libraries to connect XRootD to Pelican's p11proxy

dnf install -y openssl-pkcs11 p11-kit-server

The dependency chain explanation:
XRootD (C++) 
   ↓ uses
OpenSSL library (from openssl package, which is already bundled in Pelican)
   ↓ loads engine
PKCS#11 engine (from openssl-pkcs11 package: /usr/lib64/engines-3/pkcs11.so)
   ↓ uses
p11-kit client library (from p11-kit-server package: /usr/lib64/pkcs11/p11-kit-client.so)
   ↓ connects via Unix socket
Pelican's p11proxy server (Go code)
   ↓ provides
Signature signed by TLS key in the pelican process

(TODO: Once all reviewers approve this PR, I @h2zh need to contact BrianA & Mat to bundle these new libraries into the Pelican image build & other build workflows (KOJI/OSG/...)

Modify config parameter in pelican.yaml to enable the built-in p11 proxy in Pelican.

Server:
  EnablePKCS11: true

Make the TLS key unreadable to the xrootd user. Example:

chmod 600 /etc/pelican/certificates/tls.key
chown root:root /etc/pelican/certificates/tls.key

Spin up Pelican Registry, Director, Origin/Cache. Run Origin/Cache with verbose p11-kit logging (e.g. P11_KIT_DEBUG=rpc pelican origin serve -p 8447)

If this PR works, you can see lines as below in the Origin logs. It means pkcs11 is supplying the key and xrootd no longer need read access to the PEM TLS key file.

(p11-kit:PID) rpc_unix_init: initialized rpc socket: ...
(p11-kit:PID) rpc_C_GetSlotList: C_GetSlotList: enter ...

p11proxy: accepted connection ...

[patrickbrophy]

This is just some of the things I caught looking at the code. On a broader view, was the design always supposed to be that the service admin needs to run the commands in another shell?

[h2zh]

This is just some of the things I caught looking at the code. On a broader view, was the design always supposed to be that the service admin needs to run the commands in another shell?

This is a good point - the goal of this PR is "Pelican as a p11 server" so that the consequent XRootD development could be done. The testing recipe above provides a way to validate if Pelican can work as a p11 server.

[patrickbrophy]

This looks good @h2zh! LGTM