Application Certificates with AppScale GTS

    Posted by Graziano Obertelli on 10/2/19 6:02 PM
    Find me on:


    Application x509 Certificate

    AppScale GTS by default creates self-signed x509 certificates the first time it is deployed. These certificates are used both for internal consumption, but also to communicate with the GTS console (at port 1080) and to communicate with any application deployed within the GTS deployment. The internal certificates reside in /etc/appscale/certs named my{cert,key}.pem. Upon starting GTS, these certificates are copied to /etc/nginx and they are used for all communication with the deployment, thus the GTS admin would simply change these certs in order to install custom certificates.

    This mechanism had the benefit of being very familiar and easy for any Nginx user, and thus easy to integrate with any administrative procedure. One obvious downside was that the certificate is deployment-wide, thus if there are multiple applications deployed, only one would get the proper domain/certificate combo. This issue could be solved with a creative Nginx configuration but it may not be straightforward for non-Nginx admins. Another downside was that when a deployment was configured in HA mode with multiple load-balancer nodes, each node would need to be synchronized with new certificates and Nginx configuration.


    A certificate per application

    With the latest GTS version (3.8) each application is allowed to have its own certificate. This new feature decouples the internal self-signed certificates from the application-owned certificate. The default is still to use the self-signed certificate if no custom certificate is used. The certificates still reside in /etc/appscale/certs and on a newly deployed system you will find the usual my{cert,key}.pem. For each application, the GTS admin can now add in the above directory the application certificates: for example if my application ID is guestbook, adding guestbook.pem and guestbook.key would instruct GTS to install the custom certs.

    The custom certs will be installed in /etc/nginx with the same name, and GTS will make sure to keep them up-to-date with the ones installed by the GTS admin. This mechanism ensures that all the load-balancers will have the latest certificates. If GTS encounters issues deploying the certificate (invalid certificate, etc) it will refuse to install it, thus ensuring that Nginx can still be operating. The custom certificates will need to be installed on the shadow node.


    Something went wrong

    If the custom certificate has not been correctly detected, there are a few steps you can take to see what went wrong:

    • First of all, make sure your browser is not using a cached version of the certificate: usually using an anonymous window in your browser ensures you are going to pick up what the server provides instead;
    • Check the logs in /var/log/appscale/controller.log: there will be messages about the installation and if the certs aren’t valid, there will be errors;
    • Check the certificates themselves with openssl x509 or any other tools you are familiar with;
    • Make sure you have the full chain of intermediary in your certificates.

    Moving forward

    This step is still a manual step, that is, the GTS admin needs to copy the certificates in the right place on the shadow node, thus limiting its use to the GTS admin, not something application owner can do. The next step will be to implement a certificate API as supported in GAE, thus enabling the application owner to control it, as well as to have better error handling that is directly associated with the operation of trying to upload of certificate. Nonetheless we believe this feature simplifies enough of the use-cases to warrant a release now, without the full API implemented.

    Topics: AppScale News, AppScale Release

    Subscribe to Email Updates

    Most Popular

    Recent Posts