wiki

Changes

GC HTTPS Certificate Guidance (view source)

Revision as of 17:13, 5 October 2022

5,584 bytes added ,  17:13, 5 October 2022
no edit summary
Line 1: Line 1:     
==Certificate Recommendations and Guidance==
 
==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.
+
 
 +
In support of the HTTPS Everywhere initiative, a [https://wiki.gccollab.ca/images/9/92/Recommendations_for_TLS_Server_Certificates_-_14_May_2021.pdf Recommendations for TLS Server Certificates] 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 OCIO in close collaboration with members of the HTTPS working group including CRA, CSE, ESDC and SSC.  
 
<br><br>
 
<br><br>
 
While there are many technical details within the report that are not captured in this brief summary, the most important recommendations are:
 
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.
+
<br>
−
* 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 (e.g.: https://digital.canada.ca/). 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.
+
* '''Domain Validated (DV) server certificates are recommended''' for use by GC public facing. While the use of Organization Validated (OV) and Extended Validation (EV) certificates is not prevented, DV certificates are preferred due to their lower cost, and ability to support automated certificate issuance, for the same level of security between the web browser and web server as OV/EV certificates.  
 +
* The use of the free service provided by '''Let’s Encrypt is recommended for obtaining DV certificates''' combined with the use of [https://letsencrypt.org/docs/client-options/ compatible ACME certificate management agents] (e.g.: https://digital.canada.ca/).  
 +
** '''Note:''' This CA should be chosen by an organization who has the ability to manage their certificates, and does not need 3rd party support in the case of an outage. Let’s Encrypt is very much <u>serve yourself</u>.
 +
** Organizations should conduct a thorough assessment of the ACME agent chosen prior to installation, and as updates are made available.
 +
* Organization Validated ('''OV) certificates are not recommended''' for use, as they provide no brand or security benefits above DV certificates.
 +
* If used, '''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 (Entrust).
 +
{|
 +
|-
 +
| style="width: 500px" align="center" | [[File:Le-logo-twitter.png|250px|link=https://letsencrypt.org/]] [[file:entrust_site_seal_ssl.png|200px|link=mailto:ssc.ssltls.spc@canada.ca]]
 +
||
 +
| style="width: 500px" align="center" | For additional information, please see [https://wiki.gccollab.ca/images/9/92/Recommendations_for_TLS_Server_Certificates_-_14_May_2021.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])
 +
|}
 +
 
 +
===Enterprise Certificate Management===
 +
Recently the National Institute of Standards and Technology released [https://www.nccoe.nist.gov/projects/building-blocks/tls-server-certificate-management Special Publication 1800-16 Securing Web Transactions: TLS Server Certificate Management] for public comment. This draft practice guide provides additional information for  enterprises that rely on Transport Layer Security (TLS) to secure both customer-facing and internal applications, so they can  better manage TLS server certificates by:
 +
* Defining operational and security policies; identifying roles and responsibilities
 +
* Establishing comprehensive certificate inventories and ownership tracking
 +
* Conducting continuous monitoring of certificate operational and security status
 +
* Automating certificate management to minimize human error and maximize efficiency on a large scale
 +
* Enabling rapid migration to new certificates and keys when cryptographic mechanisms are found to be weak, compromised or vulnerable
 +
<Br>
 +
 
 +
===Automated Certificate Management Engine (ACME)===
 +
<u>[https://tools.ietf.org/html/rfc8555 RFC 8555: Automatic Certificate Management Environment]</u><br>
 +
''Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.'' For details, see the IETF document here: https://tools.ietf.org/html/rfc8555
 +
{|
 +
|-
 +
| style="width: 50%" |
 +
From the Datatracker, published 2019-03-12: https://datatracker.ietf.org/doc/rfc8555/
 +
<br><br>
 +
CAs & PKIs that offer ACME certificates (as of April 2019):
 +
# [https://www.buypass.com/ssl/acme Buypass]
 +
# [https://letsencrypt.org Let's Encrypt]
 +
# [https://www.entrustdatacard.com/knowledgebase/how-to-use-acme-to-install-ssl-tls-certificates-in-entrust-certificate-services-apache Entrust (Linux)]
 +
# [https://www.globalsign.com/en-au/auto-enrollment-gateway/ GlobalSign]
 +
# [https://www.venafi.com/ Venafi]
 +
# [https://sectigo.com/resources/sectigos-acme-automation Sectigo (formerly Comodo CA)]
 +
<br>
 +
||
 +
| style="width: 500px" align="center" |[[File:ACME-protocol-icon.png|220px|frameless]]
 +
|}
   −
[[File:Le-logo-twitter.png|250px|link=https://letsencrypt.org/]] [[file:entrust_site_seal_ssl.png|200px|link=mailto:ssc.ssltls.spc@canada.ca]]
+
===Wildcard Certificates===
 +
It is recognized that wildcard certificates offer several advantages and they may be used where appropriate, however it should be recognized that wildcard certificates may introduce certain risks depending on how they are used.
 
<br>
 
<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])
+
* Sharing the same private key (certificate) among multiple web servers may introduce additional vulnerabilities that will need to be properly mitigated.
 +
* Compromise through theft of the private key (certificate) would allow an attacker to establish rogue websites that will appear to belong to the domain protected by the wildcard certificate.
 +
* Compromise of the private key renders all TLS sessions protected by that private key vulnerable; the use of a cipher suite supporting [https://wiki.gccollab.ca/GC_HTTPS_Everywhere/Implementation_Guidance#Perfect_Forward_Secrecy_.28PFS.29 Perfect Forward Secrecy] is recommended to avoid this issue.
 +
<br>
 +
GC Website owners must ensure appropriate risk mitigation measures are in place to minimize the risk of private key compromise.
 +
* Use of FIPS 140-2 Level 2 or higher Hardware Security Modules is recommended where warranted by risk assessment or cost/benefit trade-off analysis.
 +
* In the absence of HSMs, risk mitigation measures should include effective monitoring and auditing of the system so that private key compromise can be detected as early as possible followed immediately with revocation of the associated server certificate.
 +
<br>
 +
Per the [https://wiki.gccollab.ca/images/9/92/Recommendations_for_TLS_Server_Certificates_-_14_May_2021.pdf Recommendations for TLS Server Certificates] [PDF], “care must be exercised when using multi-domain and wildcard certificates to ensure collateral damage is minimized in the event of private key compromise. Copying the same private key to multiple web servers is strongly discouraged unless appropriate risk mitigation measures are in place such as using CSE approved Hardware Security Modules to protect the private key.”
 
<br><br>
 
<br><br>
 +
Download the Recommendations for TLS Server Certificates.pdf:
 +
[[File:Pdf icon.png|75px|left|link=https://wiki.gccollab.ca/images/9/92/Recommendations_for_TLS_Server_Certificates_-_14_May_2021.pdf]]
 +
 +
<br><br><br><br><br>
 +
 
===HTTP Public Key Pinning (HPKP)===
 
===HTTP Public Key Pinning (HPKP)===
 
HPKP has been deprecated, as of end of 2017.  
 
HPKP has been deprecated, as of end of 2017.  
Retrieved from "https://wiki.gccollab.ca/Special:MobileDiff/5806...79959"