To collocate ocserv and an HTTPS server on port 443, haproxy (or similar proxy applications) could be used. haproxy allows forwarding the HTTPS port data to arbitrary servers, based on various criteria. This method, however, has the limitation that client certificate authentication cannot be enforced by ocserv as the SSL session is terminated at haproxy.

The configuration required for haproxy is something along the lines:

frontend www-https
    bind 0.0.0.0:443 ssl crt /etc/ocserv/cert-key.pem
    default_backend ocserv-backend

backend ocserv-backend
    server ocserv unix@/var/run/ocserv-conn.socket check

and ocserv must be configured to accept cleartext connections on ocserv-conn.socket file. That can be achieved using the following configuration snippet.

listen-clear-file = /var/run/ocserv-conn.socket

An alternative method to collocate ocserv and an HTTPS server on port 443, is with sniproxy. Sniproxy allows sharing the HTTPS port as long as the clients advertise the host name they connect to using server name indication (SNI). This is true for the majority of web browsers today. For this to work the web server and ocserv have to be setup to use an alternative port, e.g., ocserv uses 4443, and the web server uses 4444. A configuration of sniproxy that will redirect the traffic to the appropriate server is shown below.

listener 0.0.0.0:443 {
   protocol tls
   table TableName

   #we set fallback to be ocserv as older versions of openconnect 
   #don‘t advertise the hostname they connect to.
   fallback 127.0.0.1:4443
}

table TableName {
   # Match exact request hostnames
   vpn.example.com 127.0.0.1:4443
   www.example.com 127.0.0.1:4444
   .*\\.net    127.0.0.1:4444
}

Both of the approaches incur a performance penalty and should be considered mostly for low-traffic VPN servers and web sites.