Posts

apache2 randomly uses old self signed certificate

On a site with a valid SSL certificate, sometimes a page load would result in a warning about being insecure. When inspecting the certificate, it turned out to be an old self signed certificate that shouldn’t be in use any more since the site now has a valid “real” SSL certificate.

Reloading the page a couple of times after the problem occured, and the site loaded again with a green SSL “lock” symbol. But randomly the problem kept occuring.

Even after deleting the old self signed certificate files from the server and restarting apache2, the problem remaind.

It turned out that neither systemctl restart apache2, service apache2 restart or apachectl stop / start killed all running processes.

To verify this I did apachectl stop and then ps ax | grep apache2 revealing there where still running processes. After killing each of them manually I started apache2 again and the problem was resolved.

Is multiple CAA DNS-records allowed? Yes!

A client was about to renew one of their SSL certificates and the provider requested them to add a CAA DNS-record for the provider. The client already had one CAA DNS-record for another provider in their domain, becuase they where using different providers of SSL certificates for different purposes in their organization.

The CAA DNS-record for the provider in question was added but the provider said they couldn’t issue the certificate as long as there was another CAA DNS-record present. The provider claimed there can only be one CAA DNS-record present in the domain.

The provider might be correct in the sense of that the provider’s system can’t handle multiple CAA records but multiple CAA records is not a violation of the RFC! It is just the provider who can’t handle it and makes it the customers problem.

This might be a simple way of obstructing the client in using the provider’s competitors but the provider is not correct in their statement. According to RFC8659 there are no limitations in the number of CAA DNS-records in one domain. The provider should just look for their CAA DNS-record in the client domain DNS-records and ignore competitors records.

Ispconfig3: Let’s Encrypt not working

There can be several reasons for Let’s Encrypt certificates not being issued for sites. These are some things to check:

  • When creating a new website, save it first, then open it again and check Let’s encrypt and then save it (i.e. don’t check the Let’s Encrypt unless the website has been saved at least once in Ispconfig3)
  • Delete any existing certificates under the SSL tab for the website, including self signed
  • Check that all host names for the website and webaliases are pointing to the correct server
  • Use A records, not CNAME
  • Make sure there are no redirects on the website
  • Check for error messages in the log file; /var/log/letsencrypt/letsencrypt.log
  • If you get messages in the letsencrypt.log file like;
    “Please choose an account
    Choises: “
    Then check /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory and if there are more than one account (subdirectory) move all but one to another location.
  • Check the web logs for the site, both access and error logs, for accesses to .well-known/acme-challenge/* and verify that they are served properly (status code 200)

Samsung SL-M3375FD scan to email and SMB stopped working

Samsung multi function laser printer SL-M3375FD could suddenly not send email (scan to email) and SMB shares stopped working. Logging in to the printer web interface, using the test function for the SMTP settings just resulted in “failed” when it tried to authenticate to the email server.

Recently the email server’s SSL-certificate was updated because it was about to expire and about this time the scan to email stopped working.

The solution was simply to update the printer firmware. It was running a firmware from 2014 but updating to the latest one download here solved the problem both concerning email and SMB shares.

How to convert a certificate PFX file to CRT/KEY using openssl

Your PFX certificate file is protected with a password. It can be converted to CRT and KEY files using SSL:

openssl pkcs12 -in certfile.pfx -nocerts -out keyfile-encrypted.key

When you enter this command you will be asked to type in the pfx file password in order to extract the key. You will be asked to enter a passphrase for the encrypted key. The key will be stored in keyfile-encrypted.key.

The exported keyfile is encrypted but you might need it in unencrypted format. To unencrypt the key, do:

openssl rsa -in keyfile-encrypted.key -out keyfile.key

You will be asked for the passphrase that you entered in the previous step. The unencrypted key will be stored in keyfile.key.

Then it is time to extract the certificate:

openssl pkcs12 -in certfile.pfx -clcerts -nokeys -out certfile.crt

Again, you will need to enter the pfx file password in order to extract the certificate. The certificate will be stored in certfile.crt.

Microsoft Office 365 SSL certificate error in Outlook [solved]

Clients moving over to Office 365 who had purchased a valid SSL certificate for their mail server still got SSL certificate errors in Outlook and mobile clients. This was despite the mail service was equipped with a valid SSL certificate (not self signed, but issued by a real CA).

It turns out here that Outlook seems to investigate https root domain (i.e. the customer’s web site) for auto configuration before trying autodiscover.customerdomain.com. And if there is no valid SSL certificate installed on the customers web site, an error is displayed. This was verified by examining the customer’s web site logs where we could se repetitive accesses to /autodiscover/autodiscover.xml.

If only Outlook just would have ignored the SSL error and continued to the next method….

A simple solution was just to add a valid SSL certificate to the customer’s web site, and the problem was solved. That way Outlook didn’t get SSL certificate error when trying to retrieve the non-existing autoconfiguration information from the customer’s web site.

Fix the Heartbleed Bug on Ubuntu

OpenSSL on Ubuntu can be vulnerable to the Heartbleed Bug. Not all versions of OpenSSL are affected though. 

OpenSSL version 1.0.1 to 1.0.1f are vulnerable.
OpenSSL version 1.0.1g are not vulnerable.
OpenSSL branches 1.0.0 and 0.9.8 are not vulnerable.

To fix this issue on Ubuntu systems: 

Check your OpenSSL version to see if it is vulnerable to the bug:

openssl version

If it says 1.0.1 check the build date:

openssl version -b

If it says anything before Apr 7 2014 you need to update OpenSSL. Proceed as follows:

sudo apt-get update
sudo apt-get install openssl
sudo apt-get install libssl1.0.0

Now verify that you are running the updated OpenSSL libraries:

openssl version
openssl version -b

The build date should now come out Apr 7 2014 or later.

Now you need to regenerate your SSL certificates as they might been compromised. A guide can be found here: https://www.digitalocean.com/community/articles/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-12-04