Re: [CentOS] Certificates

2018-08-31 Thread Leo R. Lundgren
31 aug 2018 kl. 19:47 skrev Chuck Campbell :

> I am getting myself confused, and need someone who fully understands this 
> process to help me out a bot.
> 
> I would like to obtain an ssl certificate, so I can run my own imap server on 
> a machine in my office.
> 
> My domain is hosted by networksolutions, but I don't run my imap server there.
> 
> I am assuming I'll need to pay a CA to generate what I need, but I'm confused 
> about what I need. I am running dovecot at teh moment, but my clients 
> (iphone, windows laptops) say my ssl connection is not trusted. The phone 
> just won't connect.
> 
> I tried emailing the dovecot.pem file to my phone and installing it, but it 
> just says it is not trusted.
> 
> This leads me to obtaining a real CA issued certificate. I'm not sure what to 
> do with it, once I get one, and then if I need to subsequently regenerate my 
> dovecot.pem file??

Nope, you don't have to pay for a certificate at one of the traditional CAs, 
you can use Let's Encrypt to have free but fully valid certificates for your 
server.

See https://letsencrypt.org/ for more information. I can recommend 
https://github.com/xenolf/lego for use on your server, but there are many 
different LE clients out there.

If your phone does not already trust Let's Encrypt's CAs, you should be able to 
install their certificates to get it working. I suggest you start by getting a 
cert onto your server and take it from there though.

Regards, Leo
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Michael Schumacher
Leo,

>> I would like to obtain an ssl certificate, so I can run my own imap server 
>> on a machine in my office.
>> I am assuming I'll need to pay a CA to generate what I need, but
>> I'm confused about what I need. I am running dovecot at teh moment,
>> but my clients (iphone, windows laptops) say my ssl connection is
>> not trusted. The phone just won't connect.

> Nope, you don't have to pay for a certificate at one of the
> traditional CAs, you can use Let's Encrypt to have free but fully
> valid certificates for your server.

> See https://letsencrypt.org/ for more information. I can recommend
> https://github.com/xenolf/lego for use on your server, but there are
> many different LE clients out there.

certbot works only with ports 80 or 443? Can lego work with with IMAP
ports like 143 or 993? The documentation is not very clear.

best regards
---
Michael Schumacher

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Ulf Volmer
On 31.08.2018 21:31, Michael Schumacher wrote:

> certbot works only with ports 80 or 443? Can lego work with with IMAP
> ports like 143 or 993? The documentation is not very clear.

basically - independent of the client - letsencrypt will only support
http/https or dns based challenges.

so - if you want to get certificates for an imap only server, you will
have to setup an webserver for the challenge. or deal with your dns server.

best regards
Ulf
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Leo R. Lundgren
31 aug 2018 kl. 21:31 skrev Michael Schumacher :

> Leo,
> 
>>> I would like to obtain an ssl certificate, so I can run my own imap server 
>>> on a machine in my office.
>>> I am assuming I'll need to pay a CA to generate what I need, but
>>> I'm confused about what I need. I am running dovecot at teh moment,
>>> but my clients (iphone, windows laptops) say my ssl connection is
>>> not trusted. The phone just won't connect.
> 
>> Nope, you don't have to pay for a certificate at one of the
>> traditional CAs, you can use Let's Encrypt to have free but fully
>> valid certificates for your server.
> 
>> See https://letsencrypt.org/ for more information. I can recommend
>> https://github.com/xenolf/lego for use on your server, but there are
>> many different LE clients out there.
> 
> certbot works only with ports 80 or 443? Can lego work with with IMAP
> ports like 143 or 993? The documentation is not very clear.

I haven't used certbot, only lego, but that's not a problem.

If you use leo you will have it manage the request for new and renewal of 
existing certificates. It does this using challenges over HTTP or DNS. I am 
guessing this is where your understanding that it only works with port 80 and 
443 comes from - it uses either of those ports to communicate with Let's 
Encrypt's systems when using the HTTP challenge.

However, this is separate from your IMAP server. Which ports your IMAP server 
use has nothing to do with lego or the LE certificate stuff. As long as 
something, e.g. lego, successfully manages to get valid certs onto your server, 
your IMAP server should be able to use those certificates (that is, a private 
key file and a public key file). Your IMAP server can use those files and may 
then respond to requests for IMAP over SSL/TLS on e.g. port 993. Port 143 is 
for unencrypted IMAP, so in that case certificates are not relevant at all.

Consider trying leo out with the staging parameter enabled (see the 
documentation for it right there on the GitHub page), that way you can 
experiment with it and see what it produces and how it works. Then you can 
configure your IMAP server to use those certificate files.

Regards, Leo
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Leo R. Lundgren
31 aug 2018 kl. 21:38 skrev Ulf Volmer :

> On 31.08.2018 21:31, Michael Schumacher wrote:
> 
>> certbot works only with ports 80 or 443? Can lego work with with IMAP
>> ports like 143 or 993? The documentation is not very clear.
> 
> basically - independent of the client - letsencrypt will only support
> http/https or dns based challenges.
> 
> so - if you want to get certificates for an imap only server, you will
> have to setup an webserver for the challenge. or deal with your dns server.

Setting up a web server is not needed - all you need is lego (which by the way 
is one statically linked binary since it's written in Go).

If you use the HTTP challenge, lego will temporarily, only for the time needed 
to fulfill the challenge, listen for HTTP on the relevant port.

In summary, lego contains a web server for the HTTP challenge.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Robert Heller
At Fri, 31 Aug 2018 21:38:13 +0200 CentOS mailing list  
wrote:

> 
> On 31.08.2018 21:31, Michael Schumacher wrote:
> 
> > certbot works only with ports 80 or 443? Can lego work with with IMAP
> > ports like 143 or 993? The documentation is not very clear.
> 
> basically - independent of the client - letsencrypt will only support
> http/https or dns based challenges.
> 
> so - if you want to get certificates for an imap only server, you will
> have to setup an webserver for the challenge. or deal with your dns server.

Yes, this works.  I use mail.deepsoft.com for both imap and SquirrelMail and 
use the same cert for both SquirrelMail/Apache and dovecot.

> 
> best regards
> Ulf
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> 
>   

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services

 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread John Plemons
Letsencrypt.org has one other thing you should know about, not a biggie, 
the certificate is only good for 90 days at a time. Then you need to 
renew. But they though about that too, you can automate the renewal, so 
that each time the certificate expires and new one is generated and 
installed. It is supported by all of the major browsers, by supported, 
they are a part of the group that funds letsencrypt.org


john



On 8/31/2018 3:38 PM, Ulf Volmer wrote:

On 31.08.2018 21:31, Michael Schumacher wrote:


certbot works only with ports 80 or 443? Can lego work with with IMAP
ports like 143 or 993? The documentation is not very clear.

basically - independent of the client - letsencrypt will only support
http/https or dns based challenges.

so - if you want to get certificates for an imap only server, you will
have to setup an webserver for the challenge. or deal with your dns server.

best regards
Ulf
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Robert Moskowitz



On 08/31/2018 01:47 PM, Chuck Campbell wrote:
I am getting myself confused, and need someone who fully understands 
this process to help me out a bot.


I would like to obtain an ssl certificate, so I can run my own imap 
server on a machine in my office.


My domain is hosted by networksolutions, but I don't run my imap 
server there.



I am assuming I'll need to pay a CA to generate what I need, but I'm 
confused about what I need. I am running dovecot at teh moment, but my 
clients (iphone, windows laptops) say my ssl connection is not 
trusted. The phone just won't connect.


I tried emailing the dovecot.pem file to my phone and installing it, 
but it just says it is not trusted.


This leads me to obtaining a real CA issued certificate. I'm not sure 
what to do with it, once I get one, and then if I need to subsequently 
regenerate my dovecot.pem file??


Many large companies run their own CA and install their own root 
certificate.  Often installing a root cert is easier than installing a 
self-signed independent cert.  There is much written about building your 
own CA and a number of tools for that like openCA.  I can't speak for 
all your devices or apps, but there should be ways


In personal promotion, I have been doing my own CA work for ECDSA certs 
and now for EDDSA certs (and I wonder what commercial CAs are providing 
them).  See my Internet draft:


draft-moskowitz-ecdsa-pki

And my github for pending updates to this and the new eddsa-pki draft 
(to be published after openSSL 1.1.1 is released).


https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki
https://github.com/rgmhtt/draft-moskowitz-eddsa-pki

Or go to openCA or look at other CA toolkits available on Centos and Fedora.

Letsencrypt is a very important development, but it has (IMHO) a shaking 
foundation.  I would not build a production system around it.  But then 
I have lived in aspects of PKI since '95...



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread John R. Dennison
On Fri, Aug 31, 2018 at 05:30:53PM -0400, Robert Moskowitz wrote:
>
> Letsencrypt is a very important development, but it has (IMHO) a shaking
> foundation.  I would not build a production system around it.  But then I
> have lived in aspects of PKI since '95...

I presume you meant "shaky foundation"?  If so, would you care to
elaborate?






John
-- 
Many people, especially ignorant people, want to punish you for speaking the
truth, for being correct, for being you.  Never apologize for being correct,
or for being years ahead of your time.  If you're right and you know it,
speak your mind even if you are a minority of one.  The truth is still the
truth.

-- Mohandas Gandhi


pgp8FrjUuS6Z8.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Robert Moskowitz




On 08/31/2018 05:54 PM, John R. Dennison wrote:

On Fri, Aug 31, 2018 at 05:30:53PM -0400, Robert Moskowitz wrote:

Letsencrypt is a very important development, but it has (IMHO) a shaking
foundation.  I would not build a production system around it.  But then I
have lived in aspects of PKI since '95...

I presume you meant "shaky foundation"?


Yes.  I am not in California (or similar earthquake place!)  Good old 
stable Michigan (we do get mild ones once in a while.  :)



If so, would you care to elaborate


It is designed for getting web servers quickly into TLS and then to a 
more stable provider.  "Make the web safe for all".  If your content is 
short information, your contacts will never notice that you go to a new 
cert quarterly.  Long-term users might also never see this, but I can 
see web services where a new cert every 90 days will cause a pain point.


And for other services like IMAP, SMTP, LDAP (maybe not LDAP) constant 
changing certs even with a long lived root may get old for your customers.


Plan on this to 'get into the pool', but not to live with it for more 
than a year.


Unfortunately, there has never been an effective business model for 
small customers.


We are kind of close with DMARC, but I think it misses the mark. Putting 
your domain root cert into your DNSSEC signed domain should be all that 
is needed to establish a rooted trust.


I have to speak with some IETF colleagues on this (particularly in 
DNSSEC and DMARC)




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Leo R. Lundgren
1 sep 2018 kl. 00:42 skrev Robert Moskowitz :

> On 08/31/2018 05:54 PM, John R. Dennison wrote:
>> On Fri, Aug 31, 2018 at 05:30:53PM -0400, Robert Moskowitz wrote:
>>> Letsencrypt is a very important development, but it has (IMHO) a shaking
>>> foundation.  I would not build a production system around it.  But then I
>>> have lived in aspects of PKI since '95...
>> I presume you meant "shaky foundation"?
> 
> Yes.  I am not in California (or similar earthquake place!)  Good old stable 
> Michigan (we do get mild ones once in a while.  :)
> 
>> If so, would you care to elaborate
> 
> It is designed for getting web servers quickly into TLS and then to a more 
> stable provider.  "Make the web safe for all".  If your content is short 
> information, your contacts will never notice that you go to a new cert 
> quarterly.  Long-term users might also never see this, but I can see web 
> services where a new cert every 90 days will cause a pain point.
> 
> And for other services like IMAP, SMTP, LDAP (maybe not LDAP) constant 
> changing certs even with a long lived root may get old for your customers.
> 
> Plan on this to 'get into the pool', but not to live with it for more than a 
> year.
> 
> Unfortunately, there has never been an effective business model for small 
> customers.
> 
> We are kind of close with DMARC, but I think it misses the mark. Putting your 
> domain root cert into your DNSSEC signed domain should be all that is needed 
> to establish a rooted trust.
> 
> I have to speak with some IETF colleagues on this (particularly in DNSSEC and 
> DMARC)

I'm not sure I still see the point you're trying to make. What actual practical 
and concrete problems are you suggesting may arise in the situations you touch 
on above?

As far as I know, if you have a properly set up LE certificate for a service, 
and renew it regularly, clients will not have a problem with this. They trust 
the root CA, and when you renew/replace the certificate, they will happily 
trust the new one, over and over again.

Considering all relevant root trust stores now contain LE's CA, it's here to 
stay from what I can tell, not to mention it's working well so far.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-08-31 Thread Warren Young
On Aug 31, 2018, at 4:42 PM, Robert Moskowitz  wrote:
> 
> [Let’s Encrypt] is designed for getting web servers quickly into TLS

Yes.

> ...and then to a more stable provider.

[citation wanted]

> If your content is short information, your contacts will never notice that 
> you go to a new cert quarterly.

They’ll never notice regardless.

I’m looking at a Google.com certificate right now that was generated on August 
14th of this year and will not be valid past October 23.  That’s the same 
replacement schedule as Let’s Encrypt.

The old model of long-lived certificates has no special value.  It’s purely a 
business decision on the part of the providers and customers.  Automation 
removes much of this model’s value.

> I can see web services where a new cert every 90 days will cause a pain point.

Describe one.

I’ve been running some of my domains on Let’s Encrypt for years now, and have 
never had a single user complain to me that my certs are changing too often.

> And for other services like IMAP, SMTP, LDAP (maybe not LDAP) constant 
> changing certs even with a long lived root may get old for your customers.

As long as both the old and new certs are valid at the time of replacement, the 
client should care nothing about it unless they’ve gone to the trouble to 
download the cert and check it against the cached copy every time.

I remember hearing about at least one browser plugin that did this, but since 
the idea of rapid cert replacement has been gaining ground, I expect that 
plugin has lost much of the small amount of popularity it once held.

> Unfortunately, there has never been an effective business model for small 
> customers.

There is now: it’s called Let’s Encrypt. :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Walter H.

On 31.08.2018 21:31, Michael Schumacher wrote:


certbot works only with ports 80 or 443? Can lego work with with IMAP
ports like 143 or 993? The documentation is not very clear.


in case of other then Webserver you use ACME-DNS
just for a simple ACME client that is capable for ACME-DNS use acme.sh
https//acme.sh/



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Pete Biggs


> 
> so - if you want to get certificates for an imap only server, you will
> have to setup an webserver for the challenge. or deal with your dns server.
> 
Having just setup up some LetsEncrypt certificates on a CentOS server:

Certbot automates the process - if you have a webserver running, it
will use that; if you don't, it attaches a minimalistic web server to
port 80 to respond to the LetsEncrypt challenges. It's very, very easy.
(The challenges are purely to verify that you are the owner of the
domain you are asking for certificates for.)

The certificates it generates can be used for IMAP and SMTP as well.

certbot will automatically renew the certificates 2 weeks (I think)
before they expire - it does not need the web/dns challenges for
renewal. There are hooks in the process to put the renewed certificates
wherever you want, otherwise it puts them where your web server is
expecting them.

P. 



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Pete Biggs


> 
>  Your IMAP server can use those files and may then respond to
> requests for IMAP over SSL/TLS on e.g. port 993. Port 143 is for
> unencrypted IMAP, so in that case certificates are not relevant at
> all.

Well, apart from STARTTLS ...

P.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Pete Biggs


> 
> And for other services like IMAP, SMTP, LDAP (maybe not LDAP) constant 
> changing certs even with a long lived root may get old for your customers.

Why? I have corporate systems on 2 year commercial CA signed
certificates and personal servers on 90 day LetsEncrypt ones - my users
of IMAP and SMTP have never ever noticed when I changed the
certificates on any device. They certificates all have trusted CAs so
the clients trust them without any interaction.  Even I don't notice
when certbot renews my certificates.

> 
> Unfortunately, there has never been an effective business model for 
> small customers.

The problem is one of trust - in the past even significant CAs have had
their signing keys leaked, so it's difficult for the root CAs to trust
a company who deals with SMEs with cut price signing (the
infrastructure has a significant cost, so they must be cutting corners
somewhere!).

That was until LetsEncrypt comes along - it has the backing of some big
names and *IS* an effective business model for small and private
customers.

P.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Leon Fauster via CentOS
Am 01.09.2018 um 02:06 schrieb Warren Young :
> 
> I’ve been running some of my domains on Let’s Encrypt for years now, and have 
> never had a single user complain to me that my certs are changing too often.

Out of curiosity - do you change also the private key every time? 

--
LF

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Rainer Duffner


> Am 01.09.2018 um 12:51 schrieb Pete Biggs :
> 
> That was until LetsEncrypt comes along - it has the backing of some big
> names and *IS* an effective business model for small and private
> customers.


What *is* the business model of Let’s Encrypt?

Are they going to issue „Pro“ certificates at some point that cost money?

Running a CA is not expensive per se - it’s the audits that the CAB 
(CA+Browser) Forum mandates that are expensive.

In the beginning, the certificates had a certain level of trust with them that 
came both from the high prices (deterring drive-by crooks) and the fact that 
some sort of vetting was made to ensure that nobody could have issued a 
certificate for a domain they didn’t really control.

But the later step is not very friendly to automation. And CAs can principally 
issue certificates for any domain - a fact brought home by the compromise of 
Dutch CA DigiNotar in the Fall 2011.
Adding to the fact is a concentration-process in the industry that leads to 
fewer and fewer companies that know less and less of their customers.

These days, a certificate just shows that the communication is encrypted. 
Whether the other endpoint is what it claims to be is of no concern to any 
third-party involved in setting up that communication-process.

There’s even talk about deprecating the special handling browsers have for 
EV-certificates from future versions of Mozilla.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Rainer Duffner


> Am 01.09.2018 um 18:00 schrieb Leon Fauster via CentOS :
> 
> Out of curiosity - do you change also the private key every time? 



I’m pretty sure LE creates a new private key, too.
From a cursory glance at lego’s certificate directory on a server with a couple 
of dozens of LE certificates at least.
 
After all, changing the private key is what this is all about (showing that 
you’re still in charge).


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Valeri Galtsev



On 9/1/18 1:12 PM, Rainer Duffner wrote:




Am 01.09.2018 um 18:00 schrieb Leon Fauster via CentOS :

Out of curiosity - do you change also the private key every time?




I’m pretty sure LE creates a new private key, too.


I just checked on my box and confirm that yes, with every renewal of 
certificate new key is created. I should realize that fact even before 
looking, as it is asymmetric encryption pair, thus the new pair cert+key 
is generated (and the cert [request] gets signed).


Valeri


 From a cursory glance at lego’s certificate directory on a server with a 
couple of dozens of LE certificates at least.
  
After all, changing the private key is what this is all about (showing that you’re still in charge).



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Alexander Dalloz

Am 01.09.2018 um 20:27 schrieb Valeri Galtsev:
I just checked on my box and confirm that yes, with every renewal of 
certificate new key is created. I should realize that fact even before 
looking, as it is asymmetric encryption pair, thus the new pair cert+key 
is generated (and the cert [request] gets signed).


Valeri


You are commenting on a specific ACME helper tool to create LE 
certificates? On my side the key stays the same. And as long as it is 
not compromised there is no need to change it.


Alexander

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Walter H.

On 01.09.2018 20:12, Rainer Duffner wrote:



Am 01.09.2018 um 18:00 schrieb Leon Fauster via CentOS:

Out of curiosity - do you change also the private key every time?

when renewing a certificate the private key should also be changed;
other ways the renewal because of short validity period doesn't make a 
sense ...



I’m pretty sure LE creates a new private key, too.

depends on the implementation;



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Warren Young
On Sep 1, 2018, at 12:10 PM, Rainer Duffner  wrote:
> 
>> Am 01.09.2018 um 12:51 schrieb Pete Biggs :
>> 
>> That was until LetsEncrypt comes along - it has the backing of some big
>> names and *IS* an effective business model for small and private
>> customers.
> 
> What *is* the business model of Let’s Encrypt?

They’re a nonprofit, run off of sponsorships and donations:

https://letsencrypt.org/about/
https://letsencrypt.org/donate/
https://letsencrypt.org/docs/faq/
https://letsencrypt.org/sponsors/
https://letsencrypt.org/become-a-sponsor/

> Are they going to issue „Pro“ certificates at some point that cost money?

That would be incompatible with their 501(c)(3) status.

> Running a CA is not expensive per se

Indeed.

Let’s Encrypt was inevitable: the compute costs of generating certs, running 
the back-end service, and holding the data were tiny in the 1990s and are even 
tinier now.

Tiny times massive equals large, so at scale there are non-trivial costs, but 
the old standard of ~$100/yr was rapacious for what we’d now call a domain 
validation (DV) or light organization validation (OV) cert.

> In the beginning, the certificates had a certain level of trust with them 
> that came both from the high prices (deterring drive-by crooks) and the fact 
> that some sort of vetting was made to ensure that nobody could have issued a 
> certificate for a domain they didn’t really control.

I had certs in the early days, and even back then, a standard web site cert 
didn’t involve a whole lot of checking.

That’s lead to the DV vs OV vs EV distinction:

https://www.ssl.com/article/dv-ov-and-ev-certificates/

If a DV-only cert is sufficient for your purposes, then Let’s Encrypt probably 
does all you need.

The only reason to buy a cert these days is if you want OV or EV, and if it 
were me, I’d skip OV and go to EV in order to get the extra assurances that the 
green styling in the browser asserts.  For some applications, it’s worth the 
money.

DV-only covers a whole lot of use cases, though, including the one that started 
this thread.

> These days, a certificate just shows that the communication is encrypted.

You may be right that there is little practical difference to a random end user 
between DV and OV, but I believe there is real value in EV.

> There’s even talk about deprecating the special handling browsers have for 
> EV-certificates from future versions of Mozilla.

Why?

I’m aware that it’s possible to generate a fraudulent EV cert, but to deprecate 
the distinction between EV and DV is to impugn the value of the CA system 
entirely.  There’s plenty of problems in the system, which is one reason why we 
have the CAB Forum: untrustworthy CAs get run out of business.

That leaves transparent TLS proxy middleboxes and such, but that’s just another 
“Who do you trust?” argument.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Matthias Bethke via CentOS
On September 2, 2018 1:12:58 AM GMT+07:00, Rainer Duffner 
 :
>I’m pretty sure LE creates a new private key, too.
>From a cursory glance at lego’s certificate directory on a server with
>a couple of dozens of LE certificates at least.
> 
>After all, changing the private key is what this is all about (showing
>that you’re still in charge).

It doesn't hurt when the process is automated anyway but it's by no means 
necessary. The limited validity period limits how long an attacker can abuse 
the cert they should get hold of it. However if you have no reason to suspect a 
compromise, it's by no means necessary. It doesn't improve security (if you've 
been hacked in a way you don't notice, it's highly likely the new key would 
leave your system the same way the previous one did) and it's just one more 
thing that can go wrong of you so it manually.

Cheers,
Matthias
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates

2018-09-01 Thread Gordon Messmer
I use something like this script to renew my SMTP and IMAP certificates 
(/etc/cron.weekly/certbot-renew):


#!/bin/sh

hostcert=/etc/letsencrypt/live/mail.example.com
certlink="$(readlink "${hostcert}/cert.pem")"

test -x /usr/bin/certbot || exit 72

certbot certonly --quiet --standalone --keep-until-expiring \
    -d mail.example.com \
    -d imap.example.com \
    --email postmas...@example.com \
    --agree-tos --expand

# Exit if the cert hasn't been updated
test "${certlink}" = "$(readlink "${hostcert}/cert.pem")" && exit

cat ${hostcert}/fullchain.pem ${hostcert}/privkey.pem > 
/usr/lib/courier/share/esmtpd.pem
cat ${hostcert}/fullchain.pem ${hostcert}/privkey.pem > 
/usr/lib/courier/share/imapd.pem

systemctl restart courier

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates Revocation Lists and Apache...

2009-11-04 Thread nate
John Doe wrote:

>   [warn] Invalid signature on CRL
>   [error] Certificate Verification: Error (8): CRL signature failure

Any relation to this?
https://issues.apache.org/bugzilla/show_bug.cgi?id=45708

I've worked with a lot of ssl stuff in apache but have never
touched CRL before.

Interestingly enough I found last year that some of verisign's
CRLs weren't built to scale, one of our customers put some content
on their site that pointed back to us, which then triggered a call
to the CRL for those people using IE and Symantec anti virus(which
turned on the CRL option in IE), the site was a very high traffic
site and the customers routinely got errors from the CRL site
because it was overloaded with requests.

So few use CRL, I really don't see the benefit, but I suppose in
really controlled environments it could be useful(just not to me).

nate


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates Revocation Lists and Apache...

2009-11-04 Thread John Doe
From: nate 
> Any relation to this?
> https://issues.apache.org/bugzilla/show_bug.cgi?id=45708

I don't think so; my tests are quite simple:
  - Start from clean state (
  - Generate CA certificate
 
- Generate CASSL certificate signed by CA
  - Generate Client Certificate signed by CASSL
  - Generate Revocation Certificate signed by CASSL
All the steps are in one go (no changes of any kind in between).
In my tests, I am only using one crl file with one revocation certificate.
Tried the revocationpath and it did nothing at all for me...

> So few use CRL, I really don't see the benefit, but I suppose in
> really controlled environments it could be useful(just not to me).

The goal is to be able to distribute client certificates to filter web access 
to certain resources.
But we also need a way to revoke such access in the future if needed.
Lets say someone lost his laptop with his certificate or he became an evil 
hacker or he just left the company...
We need to disable his certificate, instead of having to regenerate the CASSL 
certificate and all the clients certificates... or wait for it to expire...

Thx,
JD


  
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates Revocation Lists and Apache...

2009-11-04 Thread nate
John Doe wrote:

> The goal is to be able to distribute client certificates to filter web
> access to certain resources.

How about using just basic user names and passwords? Seems a lot
simpler. Client certs can really make things messy and complicated,
I worked with them a bunch several years ago, ENDLESS headaches, and
we weren't using CRL formally at least, the application had a sort
of CRL built into it, where we specifically registered certain
CN's with the app, and apache just acted as a pass through mechanism
to the app(which was java/tomcat).

http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html

nate

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Certificates Revocation Lists and Apache...

2009-11-04 Thread Paul Heinlein
On Wed, 4 Nov 2009, John Doe wrote:

> already asked in the openssl mailing list, but just in case you already went 
> through this...
> I need a little help with Certificate Revocation Lists.
> I did setup client certificates filtering with apache and it seem to work 
> fine so far (used a tutorial on http://www.adone.info/?p=4, down right now).
> I have a "CA" that is signing a "CA SSL".
> Then, the "CA SSL" is signing the clients certificates.
>
> Now, I am testing Certificate Revocation Lists, but apache keeps 
> saying: "Invalid signature on CRL"
>
> I used:
>  $ openssl ca -config openssl.conf -name CA_ssl_default -revoke 
> cassl/$CLIENTNAME.pem
>  []
>  $ openssl ca -config openssl.conf -name CA_ssl_default -gencrl -out 
> cassl/crl.pem -crldays 365

So far so good.

> When I try to connect with a revoked (or unrevoked) certificate, I get:
>  [debug] ssl_engine_kernel.c(1199): Certificate Verification: depth: 2, 
> subject: /C=AA/ST=BB/L=CC/O=DD/CN=myhost.mydomain, issuer: 
> /C=AA/ST=BB/L=CC/O=DD/CN=myhost.mydomain
>  [debug] ssl_engine_kernel.c(1391): CA CRL: Issuer: C=AA, ST=BB, L=CC, O=DD, 
> CN=myhost.mydomain, lastUpdate: Nov  4 14:39:36 2009 GMT, nextUpdate: Nov  4 
> 14:39:36 2010 GMT
>  [warn] Invalid signature on CRL
>  [error] Certificate Verification: Error (8): CRL signature failure

Does your "CA SSL" certificate have its CRL signing bit set?

   openssl x509 -noout -purpose -in yourcert.pem | grep CRL

Also, there's an Apache bug that fouls things up if the "CA" and "CA 
SSL" root certificates both have the same CN:

   https://issues.apache.org/bugzilla/show_bug.cgi?id=45708

> How can I check if the crl.pem file is ok?
>  $ openssl crl -in cassl/crl.pem -text
>  [...]

This is the best way, and it looks as if things are OK.

> I also tried all sorts of verify combos, but all fail:
>  $ openssl verify -verbose -config openssl.conf -purpose crlsign -crl_check 
> cassl/crl.pem

The 'verify' option is only good for certifcates, not CRLs. It's also 
worth noting that the 'verify' option doesn't do any CRL checking. 
Grep for 'CRL' in the DIAGNOSTICS section of the verify(1) man page 
and you'll see a lot of 'unused' notes.

-- 
Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos