Posts Tagged ‘ssl’

[Techy] Getting cURL to work with Let’s Encrypt: unable to get local issuer certificate error

May 4th, 2016

On my test Debian jessie 8.2 and a staging server Ubuntu trusty 14.04, I had problems being able to use cURL to fetch data from a remote HTTPs site which was secured using a free Let’s Encrypt certificate (this problem manifested itself via both PHP 7 cURL functions and curl directly).

An example of the error is:

curl --verbose https://helloworld.letsencrypt.org/
...
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

To fix this, I found the following steps worked:
sudo apt-get install --reinstall ca-certificates
to ensure you have the latest certificates by your distribution – this might help you, but it didn’t assist me 🙁

So I downloaded the Let’s Encrypt root certificates and forced a rebuild of the certificate store:

sudo curl https://letsencrypt.org/certs/isrgrootx1.pem.txt -o /usr/local/share/ca-certificates/isrgrootx1.crt
sudo curl https://letsencrypt.org/certs/letsencryptauthorityx1.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx1.crt
sudo curl https://letsencrypt.org/certs/letsencryptauthorityx2.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx2.crt
sudo curl https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx1.crt
sudo curl https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx2.crt
sudo curl https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx3.crt
sudo curl https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx4.crt
sudo dpkg-reconfigure ca-certificates

and everything worked!

If you are running Java, you may need to also add the certificates to the Java Keytool:
keytool -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -noprompt -importcert -file /usr/local/share/ca-certificates/isrgrootx1.crt
keytool -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -noprompt -importcert -file /usr/local/share/ca-certificates/letsencryptauthorityx1.crt

(change the storepass password [default of “changeme”] to whatever is relevant to you)

Techy: How I investigated Counterpath Bria’s licensing issue

February 14th, 2010

On Saturday the 12th of February 2010, myself and many other users of the popular Counterpath Bria VOIP Software started getting the message “The data received from the license server appears to be corrupted. Please try again and if the problem persists, contact Counterpath Support.”, but without any idea of what caused it. Many people contacted Counterpath’s support forums, but as of the time of posting the only official status we have is “It is being investigated”. However, I took it upon myself to try and figure out what had gone wrong and then if I could “work around” the issue.

I knew from the error message that Bria was trying to contact the licensing server to validate the license, so the first step was to investigate what was being transmitted. Luckily, I had the very handy Charles Proxy and after installing its CA Certificate (so Bria didn’t complain about an invalid certificate authority when retrieving the data via Charles), I could see the communicaitons.

Bria made a post to https://secure.counterpath.com/Service/LicensePool.sv/RegisterClientBinding with my license key, a hash of something on my machine, the type of product I’m checking the license for (Bria), the time my computer thinks it is, and identifying hashes of my machine (in particular, hard disk, motherboard and Mac address) – this data is sent to try and reduce “license sharing”. In return, Counterpath sent back the same information, including an expiration date and duration of the license (30 days), instructions to recheck the license after 24 hours and then every 4 hours (+/- 30%), confirmation the license if valid and then they signed the response using an X509 digital signature. Why have they signed it? Well, otherwise it would be reasonably simple for somebody of about my technical knowledge to be able to intercept the SSL stream and modify the data to always have approved licences (and, no, I’m not going to say how I would do this – but I can think of 2 ways straight way).

As all the other data looked correct (Counterpath used descriptive XML tags which did really help in this process: although since it’s just communicating between their servers and their products, I would have personally obfuscation it just for a little more ‘security’: yes, I know “security by obfuscation” isn’t good security practice, but sometimes “every little helps”), I then investigated the X509 certificate. I copied and pasted it into a new text document, called it “x509.crt” and just let Windows’ certificate explorer show be the details – and it was immediately obvious what the fault was. The expiration date on the certificate was dated 2 days ago.

So about 5-10 minutes of investigation and I knew to roll back my computer clock to pre 12th February 2010. Run Bria to get it to reacquire a new license and viola everything working (well, hopefully for 24 hours until the license starts revalidating). I just wish Counterpath had actually provided the “roll back your clock” workaround on their forum: Bria is an excellent product and I’m just disappointed that because somebody dropped the ball and forgot to renew a 2 year old X509 certificate (which would be easily done as that length of time people would have left and the details would have just been forgotten to be passed on), their reputation and good product range may be tainted. I’m guilty myself of letting the SSL certificate on my online dance wear site expire for a couple of days (mainly because the certificate provider wouldn’t let me renew the certificate until after it had expired!) so I know how easily it can be done – I now have a 3 year certificate so it might again happen to me in 3 years time.

What has this taught us: If you use a secure certificate (for your website or code), keep a note of the date it is due to expire and set reminders. Your certificate provider might send you emails to remind you – but don’t rely on them. Communicate with your customers and if a problem could take more than a couple of hours to fix, propose a workaround (such as rolling back your computer’s clock) – they might not like it, but at least you are doing “something”. And signing license files with your own digital signature is a good idea (yep, I bet you weren’t expecting that!) as it stops people easily bypassing it – but just remember to keep your digital signature up to date!

[n.b. might just be worth mentioning that I investigated this all on my own – Counterpath or any third party did not ask me to investigate it. However, within an hour of me posting on their forums with the information I had found, the problem was fixed. Coincidence or were they already waiting for the new certificate to be approved/installed? I don’t know, but I like to speculate 😉 )

gamy-dance
%d bloggers like this: