PageSpeed HTTPS Support

PageSpeed supports sites that serve content through https. There are several mechanisms through which PageSpeed can be configured to fully optimize sites served under https:

• Use MapOriginDomain to map the https domain to an http domain.
• Use LoadFromFile to map a locally available directory to the https domain.
• Use FetchHttps to directly fetch HTTPS resources (In nginx since 1.8.31.2, in Apache since 1.7).
• Use ModPagespeedFetchFromModSpdy to fetch same-domain HTTPS resources with help of mod_spdy (Apache only).

The first two mechanisms can both be used on the same server, but they must be used for different domains, for example:

Apache:

  ModPagespeedMapOriginDomain "http://localhost" "https://www.example.com"
  ModPagespeedLoadFromFile "https://static.example.com" "/var/www/example/static/"

Nginx:

  pagespeed MapOriginDomain "http://localhost" "https://www.example.com";
  pagespeed LoadFromFile "https://static.example.com" "/var/www/example/static/";

Even without configuring any of these options, PageSpeed rewrites HTML documents requested via https. PageSpeed is able to serve these documents because the server passes the HTML document through all its output filters, including *_pagespeed. But by default, PageSpeed will only rewrite non-HTML resources which are served via http. Due to the complexity and security required to manage client SSL certificates, PageSpeed requires the server administrator to explicitly enable https fetching.

The configuration options mentioned above are intended to help optimize sites with HTTPS resources. Fetching https resource URLs using http should be used only in installations where using http is safe, such as where the server running PageSpeed is a front-end to other back-end systems with private communications and mutual trust between them.

Please read the Risks section before enabling https support.

Map the origin domain

Https resource URLs can be fetched by mapping them to a non-https origin domain as described in Mapping Origin Domains:

Apache:

  ModPagespeedMapOriginDomain "http://localhost" "https://www.example.com"

Nginx:

  pagespeed MapOriginDomain "http://localhost" "https://www.example.com";

This allows the server to accept https requests for www.example.com while fetching resources for it from the localhost http server, which could be the same Apache process or a different server process. All fetched resources will be optimized as usual. As many MapOriginDomain directives can be used as is required as long as https is only used on the second domain.

Load static files from disk

Https resource URLs can be served from static files using the LoadFromFile directive:

Apache:

ModPagespeedLoadFromFile "https://www.example.com" "/var/www/example/static/";

Nginx:

pagespeed LoadFromFile "https://www.example.com" "/var/www/example/static/";

Fetch HTTPS resources directly

Note: New feature in mod_pagespeed as of 1.7.30.1 and in ngx_pagespeed as of 1.8.31.2

HTTPS fetching is built in but is disabled by default. To turn the feature, set FetchHttps to enable:

Apache:

  ModPagespeedFetchHttps enable

Nginx:

  pagespeed FetchHttps enable;

You may set multiple options, separated with a comma. For example, to test a configuration with a self-signed certificate you could do:

Apache:

  ModPagespeedFetchHttps enable,allow_self_signed

Nginx:

  pagespeed FetchHttps enable,allow_self_signed;

The available options are

• enable
• disable
• allow_self_signed
• allow_unknown_certificate_authority
• allow_certificate_not_yet_valid

Configuring SSL Certificates

Acting as an HTTPS client, PageSpeed must be configured to point to a directory identifying trusted Certificate Authorities. These settings will be automatically applied to configuration files for new binary installations on Debian, Ubuntu, and CentOS systems. Upgrades, source-installs, and other distributions may require manual configuration updates to identify the proper location.

Apache:

  ModPagespeedSslCertDirectory directory
  ModPagespeedSslCertFile file

Nginx:

  pagespeed SslCertDirectory directory;
  pagespeed SslCertFile file;

The default directory for Debian-based systems is /etc/ssl/certs, and there is no certificate file setting. On CentOS-based systems, the default directory is /etc/pki/tls/certs and default file is /etc/pki/tls/cert.pem.

These directive cannot be used in .htaccess files or <Directory> scopes.

Rewrite domains

Rewritten resources can have their https domain rewritten if required for the reasons described in Mapping Rewrite Domains:

Apache:

  ModPagespeedMapOriginDomain "http://localhost" "https://www.example.com"
  ModPagespeedMapRewriteDomain "https://example.cdn.com" "https://www.example.com"

Nginx:

  pagespeed MapOriginDomain "http://localhost" "https://www.example.com";
  pagespeed MapRewriteDomain "https://example.cdn.com" "https://www.example.com";

Shard domains

Rewritten resources can have their https domain sharded if required for the reasons described in Sharding Domains:

Apache:

  ModPagespeedMapOriginDomain "http://localhost" "https://www.example.com"
  ModPagespeedShardDomain "https://www.example.com" \
                          "https://example1.cdn.com,https://example2.cdn.com"

Nginx:

  pagespeed MapOriginDomain "http://localhost" "https://www.example.com";
  pagespeed ShardDomain "https://www.example.com"
                        "https://example1.cdn.com,https://example2.cdn.com";

Respecting X-Forwarded-Proto

Note: New feature as of 1.1.23.1

If you are running behind a load-balancer or other front-end that terminates the HTTPS connection and makes an HTTP subrequest to your server running PageSpeed, it will not know that the original URL was HTTPS and so it will rewrite subresources with http:// URLs. For PageSpeed to operate correctly, it needs to know what the originally requested URL was. If your front-end sends X-Forwarded-Proto headers (as, for example, AWS Elastic Load Balancer does) then you can tell PageSpeed to respect that header with:

Apache:

  ModPagespeedRespectXForwardedProto on

Nginx:

  pagespeed RespectXForwardedProto on;

This will correctly rewrite your subresources with https:// URLs and thus avoid mixed content warnings. Note, that you should only enable this option if you are behind a load-balancer that will set this header, otherwise your users will be able to set the protocol PageSpeed uses to interpret the request.

This directive cannot be used in .htaccess files or <Directory> scopes.

Risks

As discussed above, using http to fetch https resources URLs should only be used when communication between the front-end and back-end servers is secure as otherwise the benefits of using https in the first place are lost. If you enable fetching by HTTPS, note that OpenSSL is used to authenticate the fetches. Please refer to that site for security advisories and best practices.

Fetching HTTPS using mod_spdy

Note: Apache-only

Note: New feature as of 1.7.30.1, and mod_spdy 0.9.4.1

If you are using both mod_pagespeed and mod_spdy, it is possible to get fetch HTTPS resources more efficiently than via ModPagespeedFetchHttps by letting the two modules cooperate. You can do so by using the option:

  ModPagespeedFetchFromModSpdy on

Note that it has no effect on fetching of resources that are not on the same domain as the webpage, and for visitors who are not using HTTPS or SPDY.

SPDY-specific configuration

Note: Apache-only

Note: New feature as of 1.1.23.1

It's possible to tell mod_pagespeed to use a different configuration for clients using the SPDY protocol than for clients using plain HTTPS or HTTP. This is done via the <ModPagespeedIf> construct. For example, you may wish to disable the combining filters when using SPDY:

  <ModPagespeedIf spdy>
  ModPagespeedDisableFilters combine_css,combine_javascript
  </ModPagespeedIf>

Similarly, it may be desirable to only turn on sharding for non-SPDY clients:

  <ModPagespeedIf !spdy>
  ModPagespeedShardDomain https://www.example.com https://example1.cdn.com,https://example2.cdn.com
  </ModPagespeedIf>

You can use <ModPagespeedIf> at top-level and virtual host scopes. The conditional blocks may contain any mod_pagespeed configuration directive that is not server global. The configurations will be applied in the following order, with latter items having precedence over earlier ones:

1. Global configuration
2. Virtual host configuration
3. Relevant <ModPagespeedIf spdy> or <ModPagespeedIf !spdy> blocks at global scope
4. Relevant <ModPagespeedIf spdy> or <ModPagespeedIf !spdy> blocks at virtual host scope
5. Path or directory-specific configuration

mod_pagespeed will consider a request to be using SPDY if it either:

• Is a SPDY request handled by mod_spdy.
• The request has the header X-PSA-Optimize-For-SPDY set, with any value. If you are using a separate proxy to terminate your SPDY connections, configuring it to set this header will therefore permit the use of this feature.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies.

Last updated August 28, 2014.