Dado o OID .1.3.6.1.4.1.1.11129.2.4.2 , descobri um artigo importante do Let's Encrypt Mergulho aprofundado em engenharia: codificação de SCTs em certificados
Let’s Encrypt recently launched SCT embedding in certificates. This feature allows browsers to check that a certificate was submitted to a Certificate Transparency log.
Comecei a fazer algumas investigações sobre o assunto e acabei descobrindo que o Google tornou obrigatória a Transparência do certificado no Google Chrome para todos os tipos de certificados X.509 a partir de 1º de maio de 2018.
Em Aplicação de transparência ao certificado no Google Chrome
This notice is being sent to all CA Operators known to the Common CA Database [1] and applies to CAs that are currently, or may in the future be, trusted on platforms on which Chrome operates (Mozilla NSS, Microsoft Windows, Apple iOS/macOS, Google ChromeOS, and Android).
We’re writing to reiterate the upcoming April 2018 Certificate Transparency (CT) enforcement in Chrome. As was first announced [2] at the CA/B Forum, followed by announcements [3] on the mozilla.dev.security.policy forum, and later updated [4] in the referenced ct-policy forum, Chrome will start enforcing that all TLS certificates issued after April 2018 comply with the Chromium CT Policy [5] in order to be trusted.
Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.
What is happening and when?
Chrome will require that all TLS server certificates issued after 30 April, 2018 be compliant with the Chromium CT Policy. After this date, when Chrome connects to a site serving a publicly-trusted certificate that is not compliant with the Chromium CT Policy, users will begin seeing a full page interstitial indicating their connection is not CT-compliant. Sub-resources served over https connections that are not CT-compliant will fail to load and will show an error in Chrome DevTools. CAs are strongly encouraged to work with their customers to ensure their TLS certificates are ready to comply with the Chromium CT Policy via any of the three means specified in RFC 6962 Section 3.3 [6] before the end of March to ensure that any issues with deploying CT support are resolved in advance of the enforcement deadline. These changes will be rolled out to Desktop platforms first, which include macOS, Windows, Linux, and ChromeOS.
In order to accommodate the unique needs of certain enterprises, there will be Chrome policies to disable CT enforcement on managed devices and for managed users that have signed-in to Chrome on their personal devices. In addition to the existing ability to disable CT enforcement by URL [7], Chrome will add a policy that allows organizations to disable CT enforcement for CAs that only issue certificates to that organization.
De Chrome requer CT após abril de 2018
Chrome will require that all TLS server certificates issued after 30 April, 2018 be compliant with the Chromium CT Policy.” This means SSL/TLS certificates must be CT qualified by meeting one of the following criteria:
A signed certificate timestamp (SCT) from a log qualified at the time of check is presented via the TLS extension OR is embedded within a stapled OCSP response, where there is at least one SCT from a Google Log, qualified at the time of check and at least one SCT from a non-Google Log, qualified at time of check.
An embedded SCT from a log qualified at the time of check is presented, where there is at least one embedded SCT from a Google Log, at least one Embedded SCT from a non-Google Log and there are the minimum number of embedded SCTs.
Então, de Transparência do certificado, uma introdução
Signed Certificate Timestamp
Certificates will typically be submitted to CT logs by the CA that issued them but it is also possible for a site owner to submit their own certificates to a log too. An SCT is the response from a Certificate Log when you submit a certificate which is essentially a promise that the certificate will be added to the log in a given amount of time. It's this SCT that we have to deliver to clients when they make a TLS connection to our site and there are 3 ways that we can do this.
x.509v3 Extension
The preferred method to deliver an SCT for a site operator is via an X.509v3 extension. This means that your CA will embed the SCT in your certificate before they sign it and issue it to you so absolutely no work or setup is required on your part. The CA will construct your certificate and prior to the last step of signing it they will submit it to the CT log as a precertificate. The log will respond with the SCT for the precertificate, the CA will embed that in the certificate and then sign it, ready for issuing to you.
TLS Extension
The SCT can also be delivered via a TLS extension from the host to the connecting client. This takes place during the TLS handshake using an extension called signed_certificate_timestamp but does require the host to update their server and configure it to deliver the SCT. The benefit here is for the CA, who doesn't have to change how they issue certificates , but waiting for reliable server implementations of the SCT TLS extension might not be great for site operators.
OCSP Stapling
I'm a fan of OCSP Stapling and it's usually used to deliver revocation information about our certificate but it can also be used to deliver the SCT from the CA to the site operator. There's a benefit for the CA again as they don't have to change their issuance process, they simply sign and issue the certificate as normal and make the SCT available via OCSP. Again though, this is a problem for us as our server needs to be able to reliably OCSP Staple and include the SCT to the client during the handshake.
Assim, acontece que os meus dois sites, um (exemplo: www.digicert.com) está tendo as extensões SCT X.509 diretamente no certificado e não precisa de modificações de configuração no lado do servidor.
No outro site (exemplo: multicert.com), o operador da CA escolhe usar o grampeamento X.509 e, como tal, o servidor da Web Apache precisa de alterações na configuração.
Eu também localizei um artigo na Digicert sobre o grampeamento do OCSP para o Apache
Para obter o site com o trabalho de grampeamento do OSCP, preciso:
- tem uma versão do Apache maior que 2.3.3
- a VM tendo comunicação com o servidor CA OCSP
-
adicionando ao vhost:
Fora do < virtualhost ... > diretiva
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)Dentro do < virtualhost ... > diretiva
SSLUseStapling onE reinicie o Apache.
Após essas alterações no site com o certificado X.509 emitido pela Multicert, o Chrome informa que os certificados são válidos em ambos os sites.
Veja também O Chrome Linux não mostra um X Extensão .509, SCT
Mais detalhes técnicos
Também me perguntaram como foi imposto o limite de tempo de 1 de maio de 2018 e o que estaria acontecendo com os certificados antigos. Sem mais detalhes palpáveis on-line, fiz o download da origem do Chromium do link com o comando:
git clone https://chromium.googlesource.com/chromium/src
Para aqueles interessantes na funcionalidade Transparência do certificado, o diretório mais interessante parece ser components/certificate_transparency/ e o arquivo doc mais interessante net/docs/certificate-transparency.md
Trechos interessantes de net/docs/certificate-transparency.md
Overview
Certificate Transparency (CT) is a protocol designed to fix several structural flaws in the SSL/TLS certificate ecosystem. Described in RFC 6962, it provides a public, append-only data structure that can log certificates that are issued by certificate authorities (CAs). By logging certificates, it becomes possible for the public to see what certificates have been issued by a given CA. This allows site operators to detect when a certificate has been issued for their domains, allowing them to check for unauthorized issuance. It also allows browsers and root stores, and the broader community, to examine the certificates a CA has issued and ensure that the CA is complying with their expected or disclosed practices. >
Basics
We say that a certificate supports Certificate Transparency if it comes with CT information that demonstrates it has been logged in several CT logs. This CT information must comply with the Certificate Transparency in Chrome policy. We sometimes refer to a site that "supports" CT as using a certificate that is "CT qualified" or "disclosed via CT."
Chrome Policies
Chrome has gradually required Certificate Transparency for more and more publicly-trusted certificates over the past few years.
Since 1 January 2015, Chrome has required that all Extended Validation certificates be disclosed via Certificate Transparency. Certificates that were not properly disclosed would be stripped of their EV status, but no warnings would be shown to visitors to sites that did not comply.
Since 1 June 2016, Chrome has required that all new certificates issued by the set of root certificates owned by Symantec Corporation are disclosed via Certificate Transparency. Certificates that were not disclosed, or which were not disclosed in a way consistent with RFC 6962, would be rejected as untrusted.
For all new certificates issued after 30 April 2018, Chrome will require that the certificate be disclosed via Certificate Transparency. If a certificate is issued after this date and neither the certificate nor the site supports CT, then these certificates will be rejected as untrusted, and the connection will be blocked. In the case of a main page load, the user will see a full page certificate warning page, with the error code
net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED. If you receive this error, this indicates that your CA has not taken steps to make sure your certificate supports CT, and you should contact your CA's sales or support team to ensure you can get a replacement certificate that works.Domain Privacy
Supporting CT by disclosing the certificate to a CT Log means that the full contents of the certificate will be publicly accessible and viewable. In particular, this means that the domains a certificate are for will be included in the Certificate Transparency log, as well as the organization they are affiliated with, if they are validated to a level higher than Domain Validation or issued from an organization-specific CA.
Nota: Curiosamente, RFC 6292 é definido como experimental
Quanto à data inicial de 2018-May-1, há instâncias codificadas específicas no código do Chromium (comuns ao Chrome), que definem a data limite que estará presente no código do Chrome / Chromium nos anos de transição. Então, isso explica o comportamento diferente na emissão de certificados antes de 1 de maio de 2018.
De serviços / rede / network_context.cc:
1525 // For old certificates (issued before 2018-05-01),
1526 // CheckCTRequirements() may return CT_NOT_REQUIRED, so we check the
1527 // compliance status here.
1528 // TODO(https://crbug.com/851778): Remove this condition once we require
1529 // signing certificates to have CanSignHttpExchanges extension, because
1530 // such certificates should be naturally after 2018-05-01.
1531 if (ct_verify_result.policy_compliance ==
1532 net::ct::CTPolicyCompliance::CT_POLICY_COMPLIES_VIA_SCTS ||
1533 ct_verify_result.policy_compliance ==
1534 net::ct::CTPolicyCompliance::CT_POLICY_BUILD_NOT_TIMELY) {
1535 ct_verify_result.policy_compliance_required = true;
1536 break;
1537 }
Em components / certificate_transparency / chrome_ct_policy_enforcer.cc:
217 // ... AND there is at least one embedded SCT from a Google Log once or
218 // currently qualified;
219 // AND there is at least one embedded SCT from a non-Google Log once or
220 // currently qualified;
221 // ...
222 //
223 // Note: This policy language is only enforced after the below issuance
224 // date, as that's when the diversity policy first came into effect for
225 // SCTs embedded in certificates.
226 // The date when diverse SCTs requirement is effective from.
227 // 2015-07-01 00:00:00 UTC.
228 const base::Time kDiverseSCTRequirementStartDate =
229 base::Time::UnixEpoch() + base::TimeDelta::FromSeconds(1435708800);
230 if (issuance_date >= kDiverseSCTRequirementStartDate &&
231 !(has_embedded_google_sct && has_embedded_nongoogle_sct)) {
232 // Note: This also covers the case for non-embedded SCTs, as it's only
233 // possible to reach here if both sets are not diverse enough.
234 return CTPolicyCompliance::CT_POLICY_NOT_DIVERSE_SCTS;
235 }
Adenda: baseado em algo que descobri depois de fazer essa investigação, e isso está detalhado em: O Chrome Linux não está mostrando uma extensão X.509, SCT
DefiniçãodoOCSPparao
