AuDigitalHealth/medserve

TLS support

Closed this issue · 10 comments

Originally reported by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


Serving Medserve using plain HTTP has a couple of problems:

  • Browser-based clients hosted using TLS are unable to make requests to it, due to security restrictions in the browser.
  • Some web APIs are disabled within insecure contexts, such as the WebCrypto API, which Polecat uses internally to generate random unique identifiers.

This is in addition to the usual problems associated with serving over HTTP, which include:

  • The potential for content-hijacking.
  • Negative influence on search engine rankings.

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


This has now been deployed and is working nicely.

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


Resolved by pull request #3.

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


This is the crontab entry:

# Run Let's Encrypt daily at 3:15 and restart Nginx, logs go to /var/log/letsencrypt
15 3    * * *   root    /usr/bin/letsencrypt certonly -n --standalone -d medserve.online && cd /root && /usr/local/bin/docker-compose restart proxy

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


I've fixed the problem with Certbot by running the following command:

ufw allow 443

There are now a set of certificate files at /etc/letsencrypt/live/medserve.online.

I'm now working on updating the Nginx configuration to use the certificates.

Original comment by Dion McMurtrie (Bitbucket: dion_mcmurtrie, GitHub: Unknown)


ssh root@medserve.online

should use the key

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


What is the username?

Original comment by Dion McMurtrie (Bitbucket: dion_mcmurtrie, GitHub: Unknown)


added, feel free to have a crack at it.

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA2zhjkEooad81vLS7X9lGBnyH/MM48rMxfC9ULhhWbWzuPnZvLPIFmsD5sqKspbXjIHymOK62UHxzK3HrKrkQxLJlMJBsAl+RumJaGzvWaa80IhW1EviBye0KtIFluduQoS4W8n2+zzCWdANsWdwf/9hNbL3c3CiNXc6kzhvelT6pfnFiuw/gtpHKeArb1s0G1oOnqVh1xNKyVeQFwhOEiCiP6bbNO2GKaMABWUNndR7ims0LaRRJkaMHvZcnQzsjc9scyeKPPi0myRdNjRArCCbZ17nWh0me2bbAlMyI/C6aSNa/7908C616uDy+GhZ+ccVbao5kVzcdpox5x6dfOQ==

Original comment by Dion McMurtrie (Bitbucket: dion_mcmurtrie, GitHub: Unknown)


I don't know what's wrong with lets encrypt. I tried using certbot but I get the following

#!bash
# certbot certonly --standalone -d medserve.online
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for medserve.online
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. medserve.online (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: medserve.online
   Type:   connection
   Detail: Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

If you give me a key I can set you up to SSH to the host.

Original comment by John Grimes (Bitbucket: j0hngr1mes, GitHub: Unknown)


If you give me access to your server I can have a go at installing Let's Encrypt.