similar to: https and self signed

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

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

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

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

I have played with self-signed end-use PKI certificates for about a decade now and would really like to set up a proper, albeit private, PKI using some sort of OFS CA management software. I have looked at OpenCA and found a few packages on sourceforge but they all seem to fall short of my desires in one form or another (rpm install, multiple subordinate CAs, certificate revocation and extension

On Fri, June 17, 2016 12:31, Valeri Galtsev wrote: > > On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > >> Keys issued to individuals certainly should have short time limits >> on them. In the same way that user accounts on systems should >> always have a near term expiry date set. People are careless. >> And their motivations are subject to change. >

On Fri, June 17, 2016 13:08, Valeri Galtsev wrote: > > We do not expire accounts until the person leaves the Department > and grace period passes. Then we do lock account and after some > time person's files are being deleted. This is the policy, and > this is what we do. The only time when account expiration is being > set is for undergraduate students who temporarily work

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: > > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree >

On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > > On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: >> >> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >>> >>> I doubt that most users check the dates on SSL certificates, >>> unless they are familiar enough with TLS to understand that >>> a shorter validity period is better for

On Sat, June 18, 2016 18:39, Gordon Messmer wrote: > On 06/18/2016 02:49 PM, James B. Byrne wrote: >> On Fri, June 17, 2016 21:40, Gordon Messmer wrote: >>> https://letsencrypt.org/2015/11/09/why-90-days.html >> With respect citing another person's or people's opinion in support >> of >> your own is not evidence in the sense I understand the word to

On 17.06.2016 16:27, ????????? ???????? wrote: > Walter H. ????? 2016-06-16 22:54: >> On 16.06.2016 21:42, ????????? ???????? wrote: >>> >>> I don't think OCSP is critical for free certificates suitable for >>> small businesses and personal sites. >>> >> this is philosophy; >> >> I'd say when you do it then do it good, else

On 17.06.2016 19:57, ????????? ???????? wrote: >>> Then OCSP stapling is the way to go but it could be a real PITA to >>> setup for the first time and may not be supported by older browsers >>> anyway. >>> >> not really, because the same server tells the client that the SSL >> certificate is good, as the SSL certificate itself; >> these must

On Mon, June 20, 2016 13:16, Gordon Messmer wrote: > On 06/20/2016 07:47 AM, James B. Byrne wrote: >> On Sat, June 18, 2016 18:39, Gordon Messmer wrote: >> >>> I'm not interested in turning this in to a discussion on >>> epistemology. >>> This is based on the experience (the evidence) of some of the >>> world's foremost experts in the

On 15.06.2016 16:17, Warren Young wrote: > On Jun 15, 2016, at 7:57 AM, ????????? ????????<nevis2us at infoline.su> wrote: >> Nowadays it's quite easy to get normal ssl certificates for free. E.g. >> >> http://www.startssl.com >> http://buy.wosign.com/free > Today, I would prefer Let?s Encrypt: > > https://letsencrypt.org/ > > It is

On Jun 15, 2016, at 9:02 AM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > I do see WoSign there (though I'd prefer to avoid my US located servers > have certificates signed by authority located in China, hence located sort > of behind "the great firewall of China" - call me superstitious). That?s a perfectly valid concern. The last I heard, modern

On Wed, June 15, 2016 10:48 am, Warren Young wrote: > On Jun 15, 2016, at 9:38 AM, Warren Young <wyml at etr-usa.com> wrote: >> >> On Jun 15, 2016, at 9:02 AM, Valeri Galtsev <galtsev at kicp.uchicago.edu> >> wrote: >> >>> I do not see neither starttls.com nor letsencrypt.org between >>> Authorities >>> certificates. >>

On 15.06.2016 15:57, ????????? ???????? wrote: > Nowadays it's quite easy to get normal ssl certificates for free. E.g. > > http://www.startssl.com > http://buy.wosign.com/free that is right, but hink of your potential clients, because wosign has a problem - slow OCSP, ... because their server infrastucture is located in China, and not the best bandwidth ... when validity checks

>> Then OCSP stapling is the way to go but it could be a real PITA to >> setup for the first time and may not be supported by older browsers >> anyway. >> > not really, because the same server tells the client that the SSL > certificate is good, as the SSL certificate itself; > these must be independent; Says who? Yes, the OCSP response comes from the same

I can't see any security advantages of a self signed cert. If the keypair is generated locally (which it should) a certificate signed by an external CA can't be worse just by the additional signature of the external CA. Better security can only be gained if all users are urged to remove all preinstalled trusted CAs from their mail clients (which seems impractical). Else an attacker could

What are the plans for the CentOS repos with respect to authentication and https everywhere? At the moment it is a trivial exercise to perform a MTM attack during a yum update over http. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited