
I've just installed a new free SSL from letsencrypt. We have paid for a SSL key but seem to have lost the private key. http://etbe.coker.com.au/2016/01/27/using-letsencrypt/ Above is a blog post I wrote about Lets Encrypt. Now I have configured the luv server to redirect all web traffic to https (let me know if that breaks anything) and to use a valid key for SMTP TLS. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On 28/01/16 00:18, Russell Coker via luv-main wrote:
I've just installed a new free SSL from letsencrypt. We have paid for a SSL key but seem to have lost the private key.
http://etbe.coker.com.au/2016/01/27/using-letsencrypt/
Above is a blog post I wrote about Lets Encrypt.
Now I have configured the luv server to redirect all web traffic to https (let me know if that breaks anything) and to use a valid key for SMTP TLS.
I've just renewed my Let's Encrypt keys for the first time, having initially set them up for my production servers during the Let's Encrypt beta. I will be setting up a cron job to do this in future. If you use the webroot authenticator instead of the "--standalone-supported-challenges tls-sni-01" option you won't need to stop the existing webserver and can have zero downtime. Cheers, Andrew

On 28/01/16 00:18, Russell Coker via luv-main wrote:
Now I have configured the luv server to redirect all web traffic to https (let me know if that breaks anything) and to use a valid key for SMTP TLS.
Note that I currently get a warning on luv.asn.au because the SSL certificate does not provide identity information. You may want to generate new certs that include the standard ownership information to prevent these warnings. Cheers, Andrew

On 28/01/16 00:34, Andrew Pam via luv-main wrote:
Note that I currently get a warning on luv.asn.au because the SSL certificate does not provide identity information. You may want to generate new certs that include the standard ownership information to prevent these warnings.
Actually it looks like that's not the main reason for the warnings - the bigger issue is that images are being served via http rather than https which means the pages are not regarded as fully secure. Cheers, Andrew

On Thu, 28 Jan 2016 12:37:56 AM Andrew Pam via luv-main wrote:
On 28/01/16 00:34, Andrew Pam via luv-main wrote:
Note that I currently get a warning on luv.asn.au because the SSL certificate does not provide identity information. You may want to generate new certs that include the standard ownership information to prevent these warnings.
Any tips on how to do that?
Actually it looks like that's not the main reason for the warnings - the bigger issue is that images are being served via http rather than https which means the pages are not regarded as fully secure.
Sounds like a Drupal issue. Lev would you like to look at it? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Argh. Ignore my previous email. Somehow instead of cancelling, I managed to send it instead :-( I replied to the wrong thing. Andrew Pam via luv-main <luv-main@luv.asn.au> writes:
Actually it looks like that's not the main reason for the warnings - the bigger issue is that images are being served via http rather than https which means the pages are not regarded as fully secure.
Actually this is particularly bad because it means cookies including session keys will be sent in the clear. Unless the cookies are marked as secure cookies, which is a really good thing - prevents accidentally leakage of the session cookie. I don't think this is the case however. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

Andrew Pam via luv-main <luv-main@luv.asn.au> writes:
On 28/01/16 00:18, Russell Coker via luv-main wrote:
Now I have configured the luv server to redirect all web traffic to https (let me know if that breaks anything) and to use a valid key for SMTP TLS.
Note that I currently get a warning on luv.asn.au because the SSL certificate does not provide identity information. You may want to generate new certs that include the standard ownership information to prevent these warnings.
Actually this is particularly bad because it means cookies including session keys will be sent in the clear. Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

Hi, I did it for 3 sites using ownCloud, just a little sooner. These are the steps I used: 1. Git download git clone https://github.com/letsencrypt/letsencrypt 2. Within the letsencrypt git area ./letsencrypt-auto --help - it downloaded and installed lots and lots of packages I wasn't expecting that :( The following NEW packages will be installed: augeas-lenses binutils cpp cpp-4.9 dh-python dialog gcc gcc-4.9 libasan1 libatomic1 libaugeas0 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4 libexpat1-dev libffi-dev libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0 libmpc3 libmpdec2 libmpfr4 libpython-dev libpython2.7-dev libpython3-stdlib libpython3.4-minimal libpython3.4-stdlib libquadmath0 libssl-dev libtsan0 libubsan0 linux-libc-dev python-chardet-whl python-colorama-whl python-dev python-distlib-whl python-html5lib-whl python-pip-whl python-requests-whl python-setuptools-whl python-six-whl python-urllib3-whl python-virtualenv python2.7-dev python3 python3-minimal python3-pkg-resources python3-virtualenv python3.4 python3.4-minimal virtualenv zlib1g-dev 3. service apache2 stop 4. ./letsencrypt-auto certonly --standalone --email owncloud-affinityiq-net-au@affinityvision.com.au -d owncloud.affinityiq.net.au 5. Checked out these notes to get my apache setup correct: https://letsencrypt.readthedocs.org/en/latest/using.html#apache # apachectl -V Server version: Apache/2.4.10 (Debian) Server built: Nov 28 2015 14:05:48 Server's Module Magic Number: 20120211:37 Server loaded: APR 1.5.1, APR-UTIL 1.5.4 Compiled using: APR 1.5.1, APR-UTIL 1.5.4 Architecture: 64-bit Server MPM: prefork threaded: no forked: yes (variable process count) Server compiled with.... -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT="/etc/apache2" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="mime.types" -D SERVER_CONFIG_FILE="apache2.conf" 6. Install cert and key for my version of apache2 cd /etc/ssl/certs mv owncloud.affinityiq.net.au.crt /root/etc_ssl_certs--owncloud.affinityiq.net.au.crt--old ln -s /etc/letsencrypt/live/owncloud.affinityiq.net.au/fullchain.pem owncloud.affinityiq.net.au.crt cd /etc/ssl/private mv owncloud.affinityiq.net.au.key /root/etc_ssl_private--owncloud.affinityiq.net.au.key--old ln -s /etc/letsencrypt/live/owncloud.affinityiq.net.au/privkey.pem owncloud.affinityiq.net.au.key 7. service apache2 start I also added the following to my apache config file: SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLProtocol All -SSLv2 -SSLv3 SSLCompression off SSLHonorCipherOrder On And this to the http version of the conf file for redirection: RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{SERVER_NAME}/ [R,L] Got an A+ here: https://www.ssllabs.com/ssltest/analyze.html?d=owncloud.affinityiq.net.au Then I did a lather, rinse, repeat for a couple of other domain names on the same server. Each time, I used a different email address; wasn't sure what it would do, but everything worked just fine. Will likely do manual cert creation from that server for other servers that need certs soon and stop using my self signed CA and certs. So far, I've only got three websites set up and only for ownCloud instances. This was the reference for the cipher setup: https://www.howtoforge.com/tutorial/how-to-setup-intermediate-compatible-ssl... Kind Regards AndrewM

Oh and I will probably up the number of bits next time I create certs, the default is RSA 2048. Cheers A.

Andrew McGlashan via luv-main <luv-main@luv.asn.au> wrote:
Oh and I will probably up the number of bits next time I create certs, the default is RSA 2048.
If they start supporting elliptic curve cryptography you'll be able to obtain reputedly stronger encryption at much reduced key lengths. I just installed the client on my KVM instance hosted at Linode and acquired a signed public-key certificate. Note that I have found the haveged package useful; it supplies random numbers to the kernel's pool by exploiting timing variability in the execution of a loop by the CPU. You can also run rngtest to evaluate the quality of the random numbers that your system is generating. A reliable hardware random number generator would of course be desirable, especially for servers.
participants (5)
-
Andrew McGlashan
-
Andrew Pam
-
Brian May
-
Jason White
-
Russell Coker