263
edits
Changes
Jump to navigation
Jump to search
==Certificate Recommendations and Guidance==
In support of the HTTPS Everywhere initiative, a recommendations [[Media:Recommendations for TLS Server Certificates.pdf|document]] was developed for the purpose of identifying the minimum requirements for TLS server certificate type and content, issuing CA conformance and website responsibilities that apply to all externally facing GC websites. This effort was led by TBS CIOB in close collaboration with members of the HTTPS working group including CRA, CSE, ESDC and SSC.
<br><br>
While there are many technical details within the report that are not captured in this brief summary, the most important recommendations are:
* Domain Validated (DV) server certificates are recommended for use by GC public facing websites. While the use of Organization Validated (OV) and Extended Validation (EV) certificates is not precluded, DV certificates are preferred due to their lower cost, the ability to support automated certificate issuance, and the fact that DV certificates provide the same level of security between the web browser and web server as OV and EV certificates.
* The use of the free service provided by Let’s Encrypt is recommended for obtaining DV certificates combined with the use of compatible certificate management agents. If used, OV and EV certificates should be obtained from SSC (contact [mailto:ssc.ssltls.spc@canada.ca ssc.ssltls.spc@canada.ca]) in order to take advantage of the reduced pricing from an approved CA vendor.
<br>
For additional information, please see [[Media:Recommendations for TLS Server Certificates.pdf|Recommendations for TLS Server Certificates]] for GC Public Facing Web Services or contact TBS-CIOB Cybersecurity ([mailto:zzTBSCybers@tbs-sct.gc.ca zzTBSCybers@tbs-sct.gc.ca])
===HTTP Public Key Pinning (HPKP)===
HPKP has been deprecated, as of end of 2017.
<br><br>
To defend against certificate misissuance, web developers should use '''Certificate Authority Authorization (CAA)''' and the <code>Expect-CT</code> header, including its reporting function. <code>Expect-CT</code> is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs.
<br><br>
Implementation of the Expect-CT header can be undertaken as follows, with a 1 year expiry: <code>http request Expect-CT: enforce, max-age=31536000, report-uri="https://example.com"</code>
<br><br>
'''Note:''' caution should be taken in implementing the <code>Expect-CT</code> header, as there is a risk of rendering your site unreachable if done wrong. In testing, it is recommended to deploy the header without the <code>enforce</code> element, and a <code>max-age</code> of 0 (zero). This arrangement will ensure that you don't block any connections with a bad certificate, however do send an error to the report-uri address (e.g.: email mailbox for simplicity's sake, or a script to handle the error and log/notify as required if desired). After testing for a period of time to provide assurance that everything still works as expected, you are able to enable the <code>enforce</code> directive, and increase the <code>max-age</code> (recommended to be 1 year - 31536000).
<br><br>
Prior to enforcing Expect-CT, be sure that your CA uses the CT logs (as they should, per certificate recommendations).
<br><br>
Set up for '''CAA''' is performed in the DNS record, explicitly naming which CA(s) are allowed to issue certificates for your website. SSL Mate has developed a very helpful tool to assist in the development of DNS entries for CAA, available [https://sslmate.com/caa/ here].
<br><br>
GC HTTPS Certificate Guidance (view source)
Revision as of 12:31, 23 October 2018
, 12:31, 23 October 2018Created page with " ==Certificate Recommendations and Guidance== In support of the HTTPS Everywhere initiative, a recommendations Media:Recommendations for TLS Server Certificates.pdf|document..."
==Certificate Recommendations and Guidance==
In support of the HTTPS Everywhere initiative, a recommendations [[Media:Recommendations for TLS Server Certificates.pdf|document]] was developed for the purpose of identifying the minimum requirements for TLS server certificate type and content, issuing CA conformance and website responsibilities that apply to all externally facing GC websites. This effort was led by TBS CIOB in close collaboration with members of the HTTPS working group including CRA, CSE, ESDC and SSC.
<br><br>
While there are many technical details within the report that are not captured in this brief summary, the most important recommendations are:
* Domain Validated (DV) server certificates are recommended for use by GC public facing websites. While the use of Organization Validated (OV) and Extended Validation (EV) certificates is not precluded, DV certificates are preferred due to their lower cost, the ability to support automated certificate issuance, and the fact that DV certificates provide the same level of security between the web browser and web server as OV and EV certificates.
* The use of the free service provided by Let’s Encrypt is recommended for obtaining DV certificates combined with the use of compatible certificate management agents. If used, OV and EV certificates should be obtained from SSC (contact [mailto:ssc.ssltls.spc@canada.ca ssc.ssltls.spc@canada.ca]) in order to take advantage of the reduced pricing from an approved CA vendor.
<br>
For additional information, please see [[Media:Recommendations for TLS Server Certificates.pdf|Recommendations for TLS Server Certificates]] for GC Public Facing Web Services or contact TBS-CIOB Cybersecurity ([mailto:zzTBSCybers@tbs-sct.gc.ca zzTBSCybers@tbs-sct.gc.ca])
===HTTP Public Key Pinning (HPKP)===
HPKP has been deprecated, as of end of 2017.
<br><br>
To defend against certificate misissuance, web developers should use '''Certificate Authority Authorization (CAA)''' and the <code>Expect-CT</code> header, including its reporting function. <code>Expect-CT</code> is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs.
<br><br>
Implementation of the Expect-CT header can be undertaken as follows, with a 1 year expiry: <code>http request Expect-CT: enforce, max-age=31536000, report-uri="https://example.com"</code>
<br><br>
'''Note:''' caution should be taken in implementing the <code>Expect-CT</code> header, as there is a risk of rendering your site unreachable if done wrong. In testing, it is recommended to deploy the header without the <code>enforce</code> element, and a <code>max-age</code> of 0 (zero). This arrangement will ensure that you don't block any connections with a bad certificate, however do send an error to the report-uri address (e.g.: email mailbox for simplicity's sake, or a script to handle the error and log/notify as required if desired). After testing for a period of time to provide assurance that everything still works as expected, you are able to enable the <code>enforce</code> directive, and increase the <code>max-age</code> (recommended to be 1 year - 31536000).
<br><br>
Prior to enforcing Expect-CT, be sure that your CA uses the CT logs (as they should, per certificate recommendations).
<br><br>
Set up for '''CAA''' is performed in the DNS record, explicitly naming which CA(s) are allowed to issue certificates for your website. SSL Mate has developed a very helpful tool to assist in the development of DNS entries for CAA, available [https://sslmate.com/caa/ here].
<br><br>
