In a new post to his site Freek Van der Herten shares some code he's worked up to validate SSL certificates in PHP to ensure they're correct when accessing a remote site.

With vanilla PHP it’s possible to check of if the SSL certificate of a given site is valid. But it’s kinda madness to do it.

He starts with the code required to do it including:

• using stream_socket_client to connect to the remote server
• getting the connection parameters with stream_context_get_params
• using openssl_x509_parse

..then on to parsing the certificate and its "valid time" timestamps. He stops it with the above steps, however, and advocates that you instead try out this package (one developed by him) to make the validation a two-line process. He also describes some of the other methods the package includes to get things like the issuer, domain and any additional domains it covers. Be aware that if you're planning on using it you'll need OpenSSL support in your PHP installation as it's required for the connection and validation.

The TutsPlus.com site has posted a tutorial for the WordPress users out there about using Let's Encrypt and SSL certificates to easily secure your installation.

For years, purchasing, renewing, installing and managing SSL certificates overwhelmed me with expense and complexity. Now, Let's Encrypt makes it fairly simple and free.

Let’s Encrypt is an emerging, free, automated, and open certificate authority brought to you by a California public benefit corporation called the Internet Security Research Group—it also has nonprofit status. [...] In this tutorial, I'll walk you through installing Let's Encrypt on a few of my websites, including my WordPress consulting website, http://lookahead.io, soon to be https://.

You'll need a be a bit comfortable working at the command line to use the Let's Encrypt client, but they walk you through each step of the process explaining everything along the way. They start with a basic list of features the Let's Encrypt service provides and the requirements you'll need to get started. Screenshots of the setup wizard are included and the "one small difference" you'll need to make when using it with WordPress. They link to the SSL Labs site to help you verify the certificate is working as expected and finish with setting up the auto-renewal of the certificate via a simple cron job.

The introduction of the LetsEncrypt free SSL certificate service has made making your site SSL only a much easier process than ever before. They've made it even easier by allowing automation around certificate setup and renewal. In this post to his site Niklas Keller shows you how to use a PHP implementation of a tool to setup/refresh your certificates automatically.

Let’s Encrypt, the free and automated CA, started late last year into their public beta. They offer a pretty comprehensive client to automate the process of getting SSL clients and installing them. It will soon be moved to a new home at EFF.

If you’re already using PHP and don’t need / want the automatic installation of your free certificates or don’t want to install Python, here’s a client for you. kelunik/acme-client is able to issue and renew certificates using your already running webserver (e.g. Nginx or Apache). It’s using the http-01 challenge to prove your domain ownership / control to Let’s Encrypt.

He shows how to use the client to set up a new LetsEncrypt account (if you don't already have one) and issue a certificate through a few command line calls. He then shows how to automate the process to check your certificate expiration and load the updated certificates. He also includes an example of the command to revoke a certificate, just in case.

On the Laravel News site there's a post showing you how to optimize your SSL support on Forge, the Laravel-related tool that makes creating and configuring servers simpler. The post focuses on a recently added feature to Forge, support for Let's Encrypt certificates, and other SSL optimizations.

Laravel Forge was recently to allow one-click installations of Let’s Encrypt certificates. It is now easier than ever to have your own SSL!

Let’s take a few extra minutes to optimize your server and help it perform faster and be more secure. In this tutorial we will look at using SSL session caching, HTTP Strict Transport Security (HSTS), and Hypertext Transfer Protocol 2 (HTTP/2).

The example they give are more Force-centric but the SSL changes and optimizations themselves could be used on any server running Nginx. They talk about:

• the SSL Log-Jam Fix
• SSL Optimizations (optimized cypher suite, OCSP stapling)
• HTTP Strict Transport Security (HSTS)
• HTTP/2

The post ends with a screenshot of how to test the new configuration and how to restart the web service to put it all into effect. There's also a link to an SSL checker that can help you verify things are set up correctly.

Kevin Schroeder has a quick post to his site showing the Magento users out there how to configure the SSL connection to their MySQL database backend.

’ve been asked a few times now if there is a way to use encrypted MySQL connections in Magento. [...] The answer, to my surprise, is that there is no way of doing it out of the box.

[...] All database configurations are stored in the local.xml file and the XML specification does not allow numbers for XML node names. So no matter how you try to slice it it looks like getting the SSL settings into the Magento adapter will not work without a code change. The Internet seems to confirm this. But that doesn’t mean that it can’t be done. So I wrote a quick Magento adapter that allows you to pass in the constant values.

He walks you through the process of getting the adapter installed, configuring MySQL to allow for the SSL connections and the configuration change to make. He includes the XML you'll need to update, including the addition of a secure_driver_options to the XML to provide the necessary SSL connection information.

In his latest post Pádraic Brady shares his thoughts about the state of TLS/SSL functionality in PHP and how he thinks developers should avoid the trap of "lowest common denominator" and opt for insecurity.

A few weeks back I wrote a piece about updating PHARs in-situ, what we’ve taken to calling “self-updating”. In that article, I touched on making Transport Layer Security (TLS, formerly SSL) enforcement one of the central objectives of a self-updating process. In several other discussions, I started using the phrase “Lowest Common Insecure Denominator” as a label for when a process, which should be subject to TLS verification, has that verification omitted or disabled to serve a category of user with poorly configured PHP installations.

This is not a novel or even TLS-only concept. All that the phrase means is that, to maximise users and minimise friction, programmers will be forever motivated to do away with security features that a significant minority cannot support by default.

He goes on to talk about how, in some places, targeting the lowest common denominator is okay, security isn't one of them. He also includes four basic concepts developers can adhere to to prevent this targeting:

• You should never knowingly distribute insecure code.
• You should accept responsibility for reported vulnerabilities.
• You should make every effort to fix vulnerabilities within a reasonable time.
• You should responsibly disclose vulnerabilities and fixes to the public.

He follows these up with three steps you can follow to migrate an insecure architecture into something much more robust. This includes identifying the consequences of the update and documenting the solutions you've chosen, be those configuration updates or library changes.

Pádraic Brady has a new post today sharing a tool he's created to enhance the current PHP file_get_contents function with a safer, more secure alternative, the humbug_get_contents library.

With the release of PHP 5.6, there was a significant security improvement in how PHP handled SSL/TLS protections, namely that it enabled a secure set of default options. Previously, SSL/TLS was disabled by default. No peer verification, no certificate checking, and a lack of configuration options had combined to create a serious problem. You can find this problem easily by searching for file_get_contents() on github and locating a call to this function used to retrieve any HTTP resource while also having zero configuration.

An excellent example of this is Composer which uses file_get_contents() instead of curl to ensure maximum compatibility with using systems. Of course, this beggars a question. If all the SSL/TLS protections are off by default in PHP 5.3-5.5…what’s stopping some irksome hacker from injecting bad code into our Composer downloads? Answer: Nothing.

The package provides a drop-in solution to the possible man-in-the-middle issues that could be caused by the native functionality. It enhances the current function with additional TLS/SSL checking for HTTPS requests on current PHP versions.

Rob Allen has a quick tip posted today about SSL certificate verification in PHP 5.6 and things that need to be updated thanks to recent improvements in PHP's SSL handling.

I recently updated my local OS X Zend Server installation to PHP 5.6 and when I ran composer self-update, I got this error message: "The "https://getcomposer.org/version" file could not be downloaded: SSL operation failed" [...] Googling around, I finally worked out that there have been various SSL improvements in PHP 5.6 and that the problem was that it couldn't find any OpenSSL certificates on my system. This isn't a total surprise as OS X has been moving away from using OpenSSL internally in favour of its own libraries.

To resolve the issue he found where PHP was looking for certificates (using openssl_get_cert_locations) and how a quick "brew install" of the needed OpenSSL handling resolved the issue. Then, in the php.ini file a quick update to the "openssl.cafile" path points it to the right certificate.

Pádraic Brady has a new "let’s watch Paddy think aloud in a completely unstructured manner blog post" about the future of security when it comes to the popular PHP package manager Composer. It's recently come under criticism around its lack of package signing and TLS/SSL support.

The Composer issue, as initially reported by Kevin McArthur, was fairly simple. Since no download connection by Composer was properly secured using SSL/TLS then an attacker could, with the assistance of a Man-In-The-Middle (MITM) attack, substitute the package you wanted to download with a modified version that communicated with the attacker’s server. They could, for example, plant a line of code which sends the contents of $_POST to the attacker’s server.

He's been working on some updates to the project, one of with is TLS/SSL support as defined in this pull request currently pending. It enables peer verification by default, follows PHP 5.6 TLS recommendations and uses local system certificates in the connection. He talks some about other additional TLS/SSL measures that could be added in the future and how, despite it being safer than nothing, TLS/SSL is not the "cure all" for the problem.

He then moves on to package signing and suggests one method for implementation - signing the "composer.phar" executable and signing "everything else" (packages to be downloaded) to verify their validity.

The flaw in Composer’s installer isn’t that it’s unsigned, it’s that it doesn’t afford the opportunity for the downloader to read it before it gets piped to PHP. It’s a documentation issue. You can go down the route of using a CA, of course, but that’s further down the rabbit hole than may be necessary. Signing the composer.phar file is another matter.

In his latest post Pádraic Brady looks at a new addition to PHP (well, to be included in the next release) related to the SSL/TLS handling it provides in streams. He's happy to report that things are improving. This commit integrated an RFC allowing for TLS perr verification in PHP streams.

The RFC reverses PHP’s course and provides PHP streams with defaults that enable both peer verification and host verification. The patch implements the RFC and it lets PHP leverage the local system’s own certificate stash (e.g. Debian’s ca-certificates) where possible to avoid PHP having to distribute a bundle of its own and while also assisting in backwards compatibility. [...] Once we have a PHP streams/sockets system with a passable level of default security, the rest will be left to programmers on the ground to change their practices.

With this new functionality coming in PHP 5.6, he strongly encourages developers to change how they're currently doing things and embrace this new verification to keep their code safer.