Implementing CT for Microsoft-based CAs

[valar...@gmail.com]

Hello all and good day to you :]

At our corporate, we have multiple CAs for different purposes. the SubCAs are chained up to Global-Sign.

One of the CAs is for SSL/TLS certificates of corporate services, we have around 4,000 TLS certs are mostly are dployed on F5 load balancers.

In the past few months, the CT subject has become more and more of a concern and now we're trying to look at our options to implement it.

Now the question is, can a CT solution be deployed in a microsoft based environment?

If yes, I assume we'll need to deploy CT Log servers in our environment and have the TLS CA issued certs uploaded to the CT logs.

do we simply go ahead and deploy those using the open-source implementation?

We highly appreciate any input/ideas here as we need to start this project as soon as possible now that we have the time (yet).

Cheers everybody, and have a wonderful day.

Val.

[Rob Percival]

Hi Val,

Because your certs chain to a public root cert, you'd need to log them to public CT logs for Chrome to accept them. That means you don't need to deploy your own CT logs. If you don't want to log them publicly, you should either re-issue them from your own private CA (in which case, Chrome will not enforce CT for them), or disable CT enforcement in Chrome for your domain(s). Bear in mind that you sacrifice some security when disabling CT.

[Rob Stradling]

On 16/02/17 10:04, 'Rob Percival' via certificate-transparency wrote:
> Hi Val,
>
> Because your certs chain to a public root cert, you'd need to log them
> to public CT logs for Chrome to accept them. That means you don't need
> to deploy your own CT logs. If you don't want to log them publicly, you
> should either re-issue them from your own private CA (in which case,
> Chrome will not enforce CT for them), or disable CT enforcement in
> Chrome for your domain(s)

> <https://www.chromium.org/administrators/policy-list-3#CertificateTransparencyEnforcementDisabledForUrls>.

> Bear in mind that you sacrifice some security when disabling CT.

Hi Val. If you don't want to switch to a private CA and you don't want
to disable CT enforcement in Chrome, then...

Your TLS server(s) will need to provide SCTs in TLS handshakes using any
of these 3 mechanisms:
1. In a certificate extension.
2. In a Stapled OCSP response extension.
3. In the signed_certificate_timestamp TLS extension.

By "microsoft based environment", I assume you mean that you're using an
instance of Microsoft Certificate Services to issue certificates and
also an instance of Microsoft's OCSP Responder software. Is that
correct? If so, then I'm afraid it's highly likely that your current
environment doesn't support any of the 3 SCT distribution mechanisms
listed above. :-(

However...
If your F5 load balancers support OCSP Stapling, then one possible
solution would be to delegate the OCSP function to another party that is
able to embed SCTs in OCSP responses on your behalf.
(I've not seen any such "OCSP Hosting" services advertised, but I know
that both Comodo and GlobalSign operate this sort of service for some
enterprise customers).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[valar...@gmail.com]

Hi Rob,

Thanks a lot for the clear answer, which leads me to the below questions. :]

Does it make any difference if we log our issued CAs to any public Logs? or is it advised to be on Global Sign CT Logs?

If we decide to upload to Google CT Logs, what do we need to do for that? Will those logs accept any certificate that's eventually chaining to a public CA?

And, what are the methods to upload certificates to the Logs (APIs, etc)?

Many thanks again for your support.

Cheers

Val.

[Florian MAURY]

Hey,

Concerning the log submission preference, you will need to submit to several logs, including Google ones AND non-Google ones, to be compliant with Google Chrome policy. I would submit to every log that might accept your certificates, if I were you. It hurts noone and it might make some convoluted attacks more difficult.

Concerning the "upload method", there are severals available, including Graham Edgecombes script (https://github.com/grahamedgecombe/ct-submit), Rob Stradling is also providing a formatting tool at crt.sh (https://crt.sh/gen-add-chain) and there might be obvious one that I am missing. Also, I am hosting a submission webservice at https://x-cli.eu/submit but this is very experimental, and you might just get a 502 error. The source code is here: https://github.com/X-Cli/ct-add-chain-webservice

Bear in mind, though that submitting a cert is not sufficient to be in the clear. You also have to provide the data contained in the submission response (the SCTs) to every web browser that sees your certificate. For this, you will need the help from your certification authority (at which point, they might as well submit the certificates for you), run experimental code on your TLS endpoint (Graham is providing a NginX patch on his github account, for instance) or ask for support of SCTs publication in TLS extension to your TLS endpoint provider.

Cheers,

Florian

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[valar...@gmail.com]

Hello Rob S.,

Many thanks for the detailed post.

Your assumption is correct, we use Microsoft CAs and Microsoft OCSP Responders.

It's sad to hear that we can't implement any of the SCT distribution mechanisms you mentioned :-(

About the alternative method on F5s, it sounds good to begin with, but we're not entirely comfortable with relying only on the F5 functionality.

Now I'm already thinking of an alternative, which is to migrate our TLS SubCA (signed by GS) to a non-Microsoft environment, namely EJBCA.

If we deploy an EJBCA CA, I suppose it possible to add the SCT extension to our issued certs and link it with a public log. Do you think that's a good solution?

Cheers

Val

[Rob Stradling]

Hi Val. If you're able to migrate to EJBCA, then yes, that should solve
your problem.

https://www.ejbca.org/docs/adminguide.html#Certificate%20Transparency%20(Enterprise%20only)

> --
> You received this message because you are subscribed to the Google
> Groups "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to certificate-transp...@googlegroups.com
> <mailto:certificate-transp...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Tomas Gustavsson]

Thanks Rob. Yes indeed, EJBCA Enterprise supports multiple of the CT ways. During issuance is most commonly used. 

How many people use the other two methods (OCSP or TLS extension stapling)?

Cheers,

Tomas

**********

PrimeKey Solutions AB

Lundagatan 16, 171 63 Solna, Sweden

Mob: +46 (0)707421096

Internet: www.primekey.se

Twitter: twitter.com/primekeyPKI

**********

[valar...@gmail.com]

Thanks a lot Rob and everybody. I totally appreciate your prompt response and help... Marvelous!

Cheers

Val.

[Eran Messeri]

On Thu, Feb 16, 2017 at 2:07 PM, Tomas Gustavsson <tomass...@gmail.com> wrote:

Thanks Rob. Yes indeed, EJBCA Enterprise supports multiple of the CT ways. During issuance is most commonly used. 

How many people use the other two methods (OCSP or TLS extension stapling)?

Depends who you ask :)

On Firefox, 36.5% of observed SCTs are from the TLS handshake, 63.5% are  embedded in certificates, only 0.03% are from stapled OCSP responses (source).

In Chrome the numbers are somewhat the other way around, I suspect that's because Chrome users communicate more with Google's servers, which serve SCTs via the TLS extension.

--

You received this message because you are subscribed to the Google Groups "certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.