Automatic Wildcard TLS Certificates
Two years ago already, the platform has started generating certificates for all the domains linked to the hosted applications in order to enable HTTPS (SSL/TLS) automatically. One limit of the feature was that wildcard domains were not compatible and our users had to keep spending their money to buy wildcard expensive certificates at third-party certificate authorities. This period is now over as Scalingo will also generate wildcard certificates automatically.
Wildcard certificates with Let's Encrypt API v2
Let's Encrypt is a certificate authority created in April 2016, that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. These certificates are only valid for 90 days, so it has to be automated in order to provide a smooth user experience. That's what we have been providing for two years now. As soon as a domain name is configured on the platform, its certificate is automatically generated and renewed.
Until this year, only certificates for precise domain names were available. It
was not possible to create a wildcard certificates covering all the subdomains
of a given domain name (i.e. *.example.com, which would work for
a.example.com, b.example.com, etc).
In March 2018, the organization released the v2 version of their API in production, and with it, the support for those wildcard certificates. The integration of this new version of their API has been deployed on Scalingo for a few months withouth any UI or UX changes for our customers. This integration also includes the support of wildcard domains. Like it's done for single domain, you just have to declare a wildcard domain and Scalingo will automatically build the corresponding TLS certificate, if the DNS configuration has been done correctly (see below).
Advantages
If your application is using a lot of different subdomains (i.e. applications using a different subdomain per client, which is usually the case for SaaS vendor), if you wanted to use our Let's Encrypt integration you had to query our API to dynamically associate or disassociate a domain. The difficulty was not so high, but it was requiring custom development and was adding lock-in to the platform, which wasn't the most convenient for our users.
Another limit was Let's Encrypt quotas which do not allow more than 50 subdomains a week being created.
Today, for this kind of use case, just create a wildcard certificate and you'll be covered for an infinite amount of subdomains.
DNS Validation
Simple domain certificates were validated through HTTP-01 challenge. However this type of validation is not available for wildcard certificates. The DNS-01 challenge has to be used.
How does it work: when a wildcard certificate is queried to Let's Encrypt using
the DNS-01 challenge, it is required to add a TXT field in the DNS zone of the
parent domain. For instance, if you want to use *.example.com, Let's Encrypt
will expect to find a precise authentication token when resolving TXT
_acme-challenge.example.com
By default, the operation is manual: when you add *.example.com to your app,
once the challenge is initialized you will receive an email notifying you and
the instruction about the content of the TXT field will be present on the
dashboard, in the Domains/SSL tab. Every two months another email is sent to
notify you updating the TXT value to update the certificate.
This method is working but requires a manual action from your side every 2
months which can be cumbersome when looking to automate processes. To solve
this issue we have integrated multiple DNS provider APIs, to automatically
update the TXT field of your domain without any manual action.
Compatible providers
Multiple providers are supported by the platform to renew automatically wildcard certificates. If yours is not present, don't hesitate to contact us, if possible, we will add it to our pool.
Configuring the integration with these third-party providers is done through
environment variables. You need to define DNS_PROVIDER according to the one
you're using, then configuration details are specific to each one. Find more
details about it in our
documentation.
The current list of providers, with the name you should use in the DNS_PROVIDER variable:
- AWS Route 53:
route53 - Google Cloud Platform DNS:
gcloud - Azure DNS:
azure - Cloudflare:
cloudflare - DNSimple:
dnsimple - OVH:
ovh - GoDaddy:
godaddy - Gandi / Gandi v5:
gandi/gandiv5
Conclusion
This feature anchors itself in our will to propagate good practices in web hosting with minimal devops impact on the day-to-day developer's life. By default valid HTTPS should be considered mandatory, and being able to do it for wildcard domains eases this process for more types of applications. Associated with the Force HTTPS feature, you can now ensure your users won't ever use your applications without being safe.
