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-fa...
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-fa...
net::ERR_CERT_AUTHORITY_INVALID
On Fri, June 17, 2016 9:56 am, Michael H wrote:
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-fa...
net::ERR_CERT_AUTHORITY_INVALID
Michael, no offense intended, but I really would suggest to do some reading instead of quoting what web browser tells you here. James gives excellent explanations, and all of them are extremely instructive. But one really needs to do a bit of reading to follow them. In a nut shell: what James described is exactly as the CA authorities operate with slight difference: propagation of private CA trust to clients.
Again, please, do some reading on the subject and then re-read what James posted. Please, do not take it as offense, James' write up is really instructive, everyone of us who ever run own Certification Authority will attest to that.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, 2016-06-17 at 15:56 +0100, Michael H wrote:
On 17/06/16 15:46, James B. Byrne wrote:
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.
net::ERR_CERT_AUTHORITY_INVALID
Your connection is not secure
The owner of harte-lyne.ca has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
On Sat, June 18, 2016 7:52 am, Always Learning wrote:
On Fri, 2016-06-17 at 15:56 +0100, Michael H wrote:
On 17/06/16 15:46, James B. Byrne wrote:
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.
net::ERR_CERT_AUTHORITY_INVALID
Your connection is not secure
The owner of harte-lyne.ca has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
You too huh? Did you, guys read what the owner of that domain wrote? I would suggest to go back to his post, and read the whole piece he wrote, not just the paragraph you left quoted here. It is instructive. And he definitely is qualifies to run Certification Authority. And can teach how to do it. That is what he did in his post.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Sat, 2016-06-18 at 08:20 -0500, Valeri Galtsev wrote:
On Sat, June 18, 2016 7:52 am, Always Learning wrote:
Your connection is not secure
The owner of harte-lyne.ca has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
You too huh?
No !
I get the similar 'Firefox version dependent' message when a new machine logs-on to a secure web site, on a non-standard port with Internet access restricted to designated individual IPs.
Instead of paying money for a "proper" certificate to access sensitive restricted applications on the Internet, I make the certificates - that is the beauty of being non-Wondoze and using Centos. ;-)
On 17.06.2016 16: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.
for your understanding: every root CA certificate is self signed; any SSL certificate that was signed by a CA not delivered as built-in token in a browser is the same as self-signed;
-
Always Learning -
James B. Byrne -
Michael H -
Valeri Galtsev -
Walter H.