Does Self Signed Certificate need CST

[Jaidil Mohan Karippara]

Hi,

Do we need to attain a CST for the certificates that we are generating using Java Keytool and using it as a self signed SSL certificate on a Apache Tomcat Server.

If we need to attain a CST, please share the documentation. I looked at the existing documentations and did not see any keytool extension commands to achieve this for a self signed certificate.

Going through this groups discussion, i saw the deadline for CST enforcement has been moved to April 2018. Is this enforcement going to be a warning to the user and if user accepts the warning, they can proceed with the connection?

Thanks,

Jaidil

[Ryan Sleevi]

I believe you mean SCT, and in that case, no, only publicly trusted certificates are expected to be accompanied with SCTs.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e5da8c37-1458-4b30-aa29-f0192dd3c429%40chromium.org.

[Jaidil Mohan Karippara]

Yes  , I was wrong . It's SCT.

One more questions, how will the chrome browser verify the SCT against a log server if there is no internet server or connection to log server?

Thanks,

Jaidil

[Ryan Sleevi]

It might be useful to review http://www.certificate-transparency.org/ to explain that :)

In the case of an SCT, much like verifying a certificate signature does not require an online connection (just a known trusted key), verifying an SCT signature does not require an online connection (just a known trusted key).

[Tres Finocchiaro]

In regards to self-signed, I'm seeking clarification on what "publicly trusted" means. This comes after being forced to create CA-like behavior for some Firefox 54+ compatibility. (Reference: https://stackoverflow.com/questions/44550970/firefox-54-stopped-trusting-self-signed-certs)

How are ISVs or local organization PKIs that do local-traffic-only-CA SSL impacted? I'm struggling to find an explanation of what would put these organizations in-scope or out-of-scope for this mandate.

Apologies for topic-hijacking, it's the first public-forum question that I could find asking this. :)

[Ryan Sleevi]

You can always create a new thread :)

Publicly-trusted means any CA that is trusted by default on any supported platform that Chrome runs on. More generally, this includes anything shipped by default by the system's root store, when that system's root store is used.

While locally-trusted CAs are still expected to conform with various aspects of RFC5280, in order to reduce the potential security issues that arise - for example, by requiring the use of a subjectAltName (as commonNames are insecure in the face of nameConstraints) or requiring the use of a signature algorithm stronger than SHA-1 - they are sometimes exempted from some policies applied to publicly trusted CAs. Disclosure via Certificate Transparency is one such exemption, as it is not possible for locally trusted CAs to log to CT logs that only trust publicly-trusted certificates.

[Tres Finocchiaro]

Publicly-trusted means any CA that is trusted by default on any supported platform that Chrome runs on. More generally, this includes anything shipped by default by the system's root store, when that system's root store is used.

Ok.  This is the part that's a bit vague reading the various material, but this information is very helpful.

 

it is not possible for locally trusted CAs to log to CT logs that only trust publicly-trusted certificates.

So to reiterate, the following (somewhat common) scenarios will **NOT** be impacted by this change:

1. A System Administrator rolls out a PKI internal to an organization that is NOT part of the OS root store
   
2. A Software Developer utilizes a locally (device-trusted) software-made CA cert that is NOT part of the OS root store

I just nudged a machine to Chrome 66, re-generated the cert for today-forward and can confirm this for the second (device-trusted) scenario.  Thank you for the quick reply.

[Ryan Sleevi]

On Tue, May 1, 2018 at 1:43 PM, Tres Finocchiaro <tres.fin...@gmail.com> wrote:

Publicly-trusted means any CA that is trusted by default on any supported platform that Chrome runs on. More generally, this includes anything shipped by default by the system's root store, when that system's root store is used.

Ok.  This is the part that's a bit vague reading the various material, but this information is very helpful.

 

it is not possible for locally trusted CAs to log to CT logs that only trust publicly-trusted certificates.

So to reiterate, the following (somewhat common) scenarios will **NOT** be impacted by this change:

1. A System Administrator rolls out a PKI internal to an organization that is NOT part of the OS root store
   
2. A Software Developer utilizes a locally (device-trusted) software-made CA cert that is NOT part of the OS root store

Depends. If it chains to a publicly trusted CA, then regardless of manual installation, it's expected.

I just nudged a machine to Chrome 66, re-generated the cert for today-forward and can confirm this for the second (device-trusted) scenario.  Thank you for the quick reply.

This is not a correct test. Could you indicate what information led you to believe it was, so we can see how best to correct that misunderstanding?

Put more specifically: CAs are expected from today onward to log their certificates in publicly trusted CT logs, and a future version of Chrome will enforce this. The policy went into effect today - but the code to enforce it will be rolled out through release channels.

[Tres Finocchiaro]

Depends. If it chains to a publicly trusted CA, then regardless of manual installation, it's expected.

Thanks for clarifying.  I was speaking around non-publicly-trusted CAs.

 

I just nudged a machine to Chrome 66, re-generated the cert for today-forward and can confirm this for the second (device-trusted) scenario.  Thank you for the quick reply.

 

This is not a correct test. Could you indicate what information led you to believe it was, so we can see how best to correct that misunderstanding?

Bleeping computer (Delivered via news-feed by Google Assistant) states... 

"Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates".

 

Put more specifically: CAs are expected from today onward to log their certificates in publicly trusted CT logs, and a future version of Chrome will enforce this. The policy went into effect today - but the code to enforce it will be rolled out through release channels.

Ok, so for clarification:

1. Unit test is incomplete and incorrect because code enforcement within Chrome 66 has not begun
   
2. Despite incomplete testing, aforementioned scenarios should **still be OK** :)

That said, is there a build (e.g. Canary) that can quickly browse a site (e.g. nontransparent-hostname(dot)org) to baseline this new behavior?

[Ryan Sleevi]

On Tue, May 1, 2018 at 2:03 PM, Tres Finocchiaro <tres.fin...@gmail.com> wrote:

Depends. If it chains to a publicly trusted CA, then regardless of manual installation, it's expected.

Thanks for clarifying.  I was speaking around non-publicly-trusted CAs.

 

I just nudged a machine to Chrome 66, re-generated the cert for today-forward and can confirm this for the second (device-trusted) scenario.  Thank you for the quick reply.

 

This is not a correct test. Could you indicate what information led you to believe it was, so we can see how best to correct that misunderstanding?

Bleeping computer (Delivered via news-feed by Google Assistant) states... 

"Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates".

Thanks. That's definitely not correct :)

 

 

Put more specifically: CAs are expected from today onward to log their certificates in publicly trusted CT logs, and a future version of Chrome will enforce this. The policy went into effect today - but the code to enforce it will be rolled out through release channels.

Ok, so for clarification:

1. Unit test is incomplete and incorrect because code enforcement within Chrome 66 has not begun
   
2. Despite incomplete testing, aforementioned scenarios should **still be OK** :)

That said, is there a build (e.g. Canary) that can quickly browse a site (e.g. nontransparent-hostname(dot)org) to baseline this new behavior?

With Chrome 67+, you can manually/locally test, using the syntax documented in

https://chromium.googlesource.com/chromium/src/+/ba39855616fae47148cf7da3c80d1dad6cf6e966

Technically, you can set this policy on Chrome 66, but you particularly shouldn't - there was a logic bug which would also enforce that testing flag on locally installed certificates (which would never meet). That was fixed in https://chromium.googlesource.com/chromium/src/+/01e94e1c9684b8c8ad19ca67c0f0b41c2fa64517 (aka Chrome 67)

[Tres Finocchiaro]

Ok, using the aforementioned syntax, I can successfully get Chrome Canary (68.0 at the time of writing this) to throw NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED using letsencrypt.org.

https://i.imgur.com/8AGBS2v.png

(this was just a lucky guess)

The command was (on Windows):

"%localappdata%\Google\Chrome SxS\Application\chrome.exe" --enable-features="EnforceCTForNewCerts<EnforceCTTrial" --force-fieldtrials="EnforceCTTrial/Group1" --force-fieldtrial-params="EnforceCTTrial.Group1:date/1512086400"

(1512086400 = 2017-12-01 00:00:00 UTC, per commit notes)

I can confirm using the same unit-test above that the locally-generated (locally-trusted-only) CA certificate is **NOT** affected. :)

Thank you kindly for this information!