Add certificate status gating for PVA TLS connections

[george-mcintyre]

Overview

After a TLS handshake, if the peer certificate contains a certificate status PV name (stored in the custom OID 1.3.6.1.4.1.37427.1), the connection now waits for that PV to report VALID before allowing data operations. This implements the PVA TLS certificate status protocol, matching PVXS behaviour.

Behaviour

Scenario	Result
Status PV reports VALID within timeout	Connection proceeds normally
Status PV not confirmed within EPICS_PVA_CERT_STATUS_TMO (default 30 s)	Degraded mode: data operations released with a warning logged
Status PV reports REVOKED or EXPIRED	Connection is immediately shut down
Certificate has no status PV OID	No gating; connection proceeds immediately

Client side

• ClientTCPHandler starts a CertificateStatusMonitor after a successful TLS handshake.
• Data operations are gated on a CompletableFuture that resolves when the status PV responds.
• The monitor uses a PVAClient(tls_disabled=true) to avoid infinite recursion (cert-status monitoring cannot itself require cert-status monitoring).
• OCSP responses are tracked with expiry timers; when an OCSP response expires the connection re-validates.

Server side

• ServerTCPListener and ServerTCPHandler start a CertificateStatusMonitor for the client certificate after TLS handshake.
• CreateChannelHandler gates its reply on the client certificate status being VALID.

Configuration

Variable	Default	Description
EPICS_PVA_CERT_STATUS_TMO	30	Seconds to wait for cert status PV before entering degraded mode

Dependencies

This branch includes the prerequisite commits for XDG keychain discovery, keychain password file support, CA certificate extraction, and DER double-unwrap, since the certificate status monitor relies on SecureSockets and PVASettings helpers introduced in those changes. Those changes are also submitted as standalone PRs:

• Fix CA certificate extraction from PKCS12 key entry chains (Fix CA certificate extraction from PKCS12 key entry chains in SecureSockets #3779)
• Fix double-layered DER encoding in certificate extension decoding (Fix double-layered DER decoding when reading X.509 certificate extension OIDs #3780)
• Add XDG standard path auto-discovery for PVA TLS keychains (Add XDG standard path auto-discovery for PVA TLS keychains #3782)
• Add EPICS_PVA_TLS_KEYCHAIN_PWD_FILE for file-based keychain password (Add EPICS_PVA_TLS_KEYCHAIN_PWD_FILE for file-based keychain password #3783)

Files Changed

• core/pva/src/main/java/org/epics/pva/PVASettings.java
• core/pva/src/main/java/org/epics/pva/client/ClientTCPHandler.java
• core/pva/src/main/java/org/epics/pva/common/CertificateStatus.java
• core/pva/src/main/java/org/epics/pva/common/CertificateStatusMonitor.java
• core/pva/src/main/java/org/epics/pva/common/SecureSockets.java
• core/pva/src/main/java/org/epics/pva/server/CreateChannelHandler.java
• core/pva/src/main/java/org/epics/pva/server/ServerTCPHandler.java
• core/pva/src/main/java/org/epics/pva/server/ServerTCPListener.java

[sonarqubecloud]

Quality Gate passed

Issues
45 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kasemir]

I would defer this because it is a significant change with no immediate need.

This Java implementation aims to be compatible with the C++ (PVXS) implementation. This includes the PVXS security additions which as of now have not been released. Java servers and clients can use the same certificates as PVXS servers and clients.
For a PVA server, it is essential to know the identity of the PVA client. That way, write access to PVs can be controlled based on the trusted client authentication. While the Java PVA server so far sees very little use (https://github.com/controlSystemStudio/pvaify is the only known utility that depends on it), the Java PVA server does already implement the client certificate verification based on optional CERT:STATUS:.. PVs provided by PVACMS.
For the client, there is no immediate need to verify the server identity because there is no mechanism to use that information. PV names are not tied to specific IOCs. Clients do not keep a white list of approved servers.
The client-side check of a server certificate should thus be delayed until the PVXS implementation settles into a release, and maybe even further until clients start to adopt mechanisms that require the server cert validation.