Securing Access with HTTPS

By the end of this lesson, you will be able to:

  • Explain why HTTPS is essential for a production Connect deployment
  • Describe the roles TLS certificates and private keys play in securing access
  • Identify where certificates should live and how they should be permissioned
  • Recognize the configuration changes Connect needs to serve traffic over HTTPS

Introduction

By default, Connect serves traffic over unencrypted HTTP. For any deployment beyond initial testing, you need to configure HTTPS so traffic between your users and the server, including credentials and the content they publish and view, is encrypted and cannot be intercepted or tampered with.

Understanding HTTPS configuration using TLS certificates is essential for any production Connect deployment. This lesson explains the concepts behind securing Connect with HTTPS. The accompanying lab walks you through placing certificates correctly, setting their permissions, and configuring Connect to use them.

NoteTimings for this chapter
  • Reading time: 10 minutes
  • Documentation reading time: 5 minutes
  • Hands-on exercise time: 15-30 minutes
TipRequired Reading

What TLS Provides

TLS (Transport Layer Security) secures the connection between a client and a server using two related files: a certificate and a private key.

The certificate is presented to clients and identifies your server. It is not secret: it is meant to be shared, which is why it can be readable by others. The private key, by contrast, is the secret that proves the server owns that certificate. If the private key is exposed, the security of the connection is compromised, so it must be readable only by the service account that runs Connect. This asymmetry is the reason the certificate and private key have different permission settings.

Certificates must be in PEM format, and the file should contain the full certificate chain. Private keys cannot be protected with a passphrase; if yours has one, the documentation provides a command to remove it.

Certificate Placement and Permissions

Posit recommends storing the certificate and private key alongside the other Connect configuration files, in /etc/rstudio-connect/. Keeping them with the rest of the configuration makes the deployment easier to reason about and back up.

Both files must be owned by the Connect service account so that Connect can read them. Their modes differ to reflect their sensitivity: the certificate can be world-readable (mode 644), while the private key must be readable only by its owner (mode 600). Getting these permissions wrong is a common cause of Connect failing to start after a TLS change.

Before configuring Connect, you can inspect your certificate with openssl x509 -text -noout -in <path_to_certificate_file.crt>. This checks that the file is in PEM format and lets you confirm the full certificate chain is present.

How Connect Serves HTTPS

Enabling HTTPS requires a handful of settings in rstudio-connect.gcfg and a restart of the service:

  1. Server.Address must use https:// for the URL of your Connect installation.
  2. HTTPS.Listen sets the port Connect listens on for HTTPS, typically :443, the default port for HTTPS.
  3. HTTPS.Certificate and HTTPS.Key point to the full paths of the certificate and its key.
  4. HTTPS.Permanent = true tells Connect to only allow the HTTPS protocol.
  5. HTTPRedirect.Listen (typically :80) sets up HTTP to HTTPS redirection.

Note that the notation Server.Address refers to the setting Address within the [Server] section of the configuration file.

Once configured and restarted, users reach Connect over https://, and HTTP requests are redirected to the secure endpoint. You can confirm the change by visiting your instance URL and checking that the browser shows a valid certificate.

TipWhy is it relevant to me?

As you plan the installation of Connect on your own infrastructure, keep these questions in mind:

  • Do you know where you will get the SSL/TLS certificates you will need?
  • Will you need security approvals before you can put certificates on the server?
  • Plan to check that the full certificate chain is available in your certificate, and that the private key is not protected with a passphrase.

In the accompanying lab, you will move the certificate and its key into place, set their ownership and permissions, and edit the configuration file so Connect serves traffic over HTTPS.