websockify has IMHO a security flaw when it come to the use of SSL.

On any systems, it's recommended, to restrict the access to the SSL key and certificate. On Debian systems, all the keys and certs under /etc/ssl/private/ are only readable by the root user.
First solution:
websockify has to be started as root user to be able to read the certificate information under /etc/ssl/private/. If websockify has a vulnerability (yet or in the future, hope not), it might be possible to gain root access.
The second solution is to create a specific user for the websockify service, similar to the 'www-data' user for Apache. In this case, the websockify user must be able to read the certificate on startup. This can only be achieved by granting 'world' access to the certificate under /etc/ssl/private/. This might break other applications using the same certificate and performing a check if the certificate permissions are correct. Some application don't even startup if the permission are incorrect.

The only solution to this problem is using a SSL termination proxy in front of websockify.
1.) Start websockify under a specific websockify system user listen to localhost:<websockifyPort> without SSL support -> sudo -u websockify /opt/local/websockify localhost:<websockifyPort>
2.) Use a SSL termination proxy like stunnel and setup the port binding setting like accept=<publicPort>, connect=localhost:<websockifyPort>

stunnel is one of the only SSL termination proxy that are capable dealing with websocket upgrades. NGINX has recently added websocket support.

An other possible solution is, to start the server as root, read the certificate in memory and change the uid/gid of the process.
supervisord is doing this here. This can also be added to websockify here with a newly introduced parameter --user/--group.