On 17/06/16 15:46, James B. Byrne wrote:
>
> On Thu, June 16, 2016 13:53, Walter H. wrote:
>> On 15.06.2016 16:17, Warren Young wrote:
>>> but it also affects the other public CAs: you can’t get a
>>> publicly-trusted cert for a machine without a publicly-recognized
>>> and -visible domain name. For that, you still need to use
>>> self-signed certs or certs signed by a private CA.
>>>
>> A private CA is the same as self signed;
>>
>
> No it is not. A private CA is as trustworthy as the organisation that
> operates it. No more and not one bit less.
>
> We operate a private CA for our domain and have since 2005. We
> maintain a public CRL strictly in accordance with our CPS and have our
> own OID assigned. Our CPS and CRL together with our active, expired
> and revoked certificate inventory is available online at
> ca.harte-lyne.ca. Our CPS states that we will only issue certificates
> for our own domain and furthermore we only issue them for equipment
> and personnel under our direct control.
>
> In a few years DANE is going to destroy the entire market of 'TRUSTED'
> root CA's -- because really none of them are trust 'worthy' --. And
> that development is long overdue. When we reach that point many
> domains, if not most, will have their DNS forward zones providing TLSA
> RRs for their domain CA certificates and signatures. And most of
> those that do this are going to be running their own private CA's
> simply to maintain control of their certificates.
>
> Our DNS TLSA flags tell those that verify using DANE that our private
> CA is the only authority that can issue a valid certificate for
> harte-lyne.ca and its sub-domains. Compare that to the present case
> wherein any 'trusted' CA can issue a certificate for any domain
> whatsoever; whether they are authorised by the domain owner or not[1].
> So in a future with DANE it will be possible to detect when an
> apparently 'valid' certificate is issued by a rogue CA.
>
> The existing CA structure could not have been better designed for
> exploitation by special interests. It has been and continues to be so
> exploited.
>
> Personally I distrust every one of the preloaded root CAs shipped with
> Firefox by manually removing all of their trust flags. I do the same
> with any other browser I use. I then add back in those trusts
> essential for my browser operation as empirical evidence warrants.
> So I must trust certain DigiCert certificates for GitHub and
> DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
> These I set the trust flags for web services only. The rest can go
> pound salt as we used to say.
>
>
> [1]
> https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
>
https://harte-lyne.ca/
net::ERR_CERT_AUTHORITY_INVALID
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
