Re: new install on Centos 7

[Peter]

On 11/08/17 10:42, Joseph Tam wrote:
>> Or just ping me in #ghettoforge on Freenode and I'll generally get it
>> fixed quickly, if I haven't already seen it on the list and fixed it.
> 
> Not all package maintainers are as responsive as you are.  I've lost
> count of the number of problems reported here, where people could not
> move from version 1.x, because their repo did not have anything newer, or
> for reason out of their control, they can't update because it would/could
> break something else.

Oh, I know, and I'll take that as a compliment :-)

>> There are downsides to compiling yourself.
> 
> To be sure.  (Incidentally, auto-updates are sometimes *not* what
> people want -- stability of a working system is paramount over
> anything that might jeopardize that.)

Right, but I didn't say "auto-updates", I said regular updates, which
could be auto-updates but could also just be regular running of "yum
update" by a human who can intervene if it blows up.  It could also be a
fully controlled test environment where someone does full regression
testing before pushing updates out to 500 other servers in a farm.

> Compiling from source is not everybody's cup of tea, but it does allow
> complete control over the build.  Repo-packages usually are built with
> kitchen-sink options, which may not suit everyone.

I would encourage that if you want to go that route that you actually
build your own packages and install them rather than installing directly
from source.  This takes advantage of the many features of package
systems such as the ability to verify installs in case tampering is
suspected, dependency resolution, and the ability to easily revert to a
prior version if something goes wrong.

I am more than happy for anyone who wants to do this to download and use
the .src.rpm files from GhettoForge as a base for their own package builds.


Peter

Re: Certificate cache on iOS with sending mail

[Alef Veld]

And iPhone just sits there for a long time, "sending". Sometimes it goes 
through sometimes it doesn't.

It's super weird but it has to do with SSL_accept and not reading the message 
fully. 

I might restore my old certs see if that solves it. I'll try some other clients 
and ip addresses as well, outlook or something.

Sent from my iPhone

> On 11 Aug 2017, at 00:08, Alef Veld  wrote:
> 
> I deleted the certificate already, but I think it only uses that for 
> imap/dovecot. I don't think it actually stores one for smtps (or am I not 
> talking sense here).
> 
> Sent from my iPhone
> 
>> On 10 Aug 2017, at 23:25, Joseph Tam  wrote:
>> 
>> 
>>> On Thu, 10 Aug 2017, Larry Rosenman wrote:
>>> 
>>> Which mail client on iOS?
>> 
>> Sorry, maybe not iOS, but definitely MacOSX Mail app.
>> 
>> Joseph Tam 

Re: Certificate cache on iOS with sending mail

[Alef Veld]

I deleted the certificate already, but I think it only uses that for 
imap/dovecot. I don't think it actually stores one for smtps (or am I not 
talking sense here).

Sent from my iPhone

> On 10 Aug 2017, at 23:25, Joseph Tam  wrote:
> 
> 
>> On Thu, 10 Aug 2017, Larry Rosenman wrote:
>> 
>> Which mail client on iOS?
> 
> Sorry, maybe not iOS, but definitely MacOSX Mail app.
> 
> Joseph Tam 

Re: Certificate cache on iOS with sending mail

[Alef Veld]

macOS mail for sure, latest OS.
I know it's not a dovecot issue, but I can't be sure as this all started after 
I changed my dovecot cert. Does smtps using saslauthd through dovecot not have 
anything to do with it? (But tls in main.cf uses different certs.

Anyway the bizarre thing is that my MacBook still happily sends and receives 
mail. I noticed an additional error today though, SSL_accept error. This seems 
to coincide with the -1 error, it only reads a few bytes. 

Something went wrong and I don't know how to fix it. I deleted the accounts, 
but it doesn't even verify it anymore. Dovecot works fine, but no more sending 
mail. All because I changed the dovecot cert seemingly.

So yes I think it's a local issue, and something is stuck in limbo. but no clue 
on how to fix it. The iPhone mysteriously started working again this afternoon. 

Sent from my iPhone

> On 10 Aug 2017, at 23:25, Joseph Tam  wrote:
> 
> 
>> On Thu, 10 Aug 2017, Larry Rosenman wrote:
>> 
>> Which mail client on iOS?
> 
> Sorry, maybe not iOS, but definitely MacOSX Mail app.
> 
> Joseph Tam 

Re: new install on Centos 7

[Joseph Tam]

Or consider compiling it yourself from source.  It may be more work, but
you get complete control over your versioning, your package dependencies,
etc.  If a bug that affects you gets fixed on a bleeding edge version
(or is only available as a patch), you can fix it right away rather than
waiting for the package maintainer to catch up to it.


Or just ping me in #ghettoforge on Freenode and I'll generally get it
fixed quickly, if I haven't already seen it on the list and fixed it.


Not all package maintainers are as responsive as you are.  I've lost
count of the number of problems reported here, where people could not
move from version 1.x, because their repo did not have anything newer, or
for reason out of their control, they can't update because it would/could
break something else.


There are downsides to compiling yourself.


To be sure.  (Incidentally, auto-updates are sometimes *not* what
people want -- stability of a working system is paramount over
anything that might jeopardize that.)

Compiling from source is not everybody's cup of tea, but it does allow
complete control over the build.  Repo-packages usually are built with
kitchen-sink options, which may not suit everyone.

Joseph Tam 

Re: Certificate cache on iOS with sending mail

[Joseph Tam]

On Thu, 10 Aug 2017, Larry Rosenman wrote:


Which mail client on iOS?


Sorry, maybe not iOS, but definitely MacOSX Mail app.

Joseph Tam 

Re: is a self signed certificate always invalid the first time?

[Doug Hardie]

Having gone through the process to get "approved" certificates a few times, I 
don't believe it would be all that difficult to get a certificate with your 
domain name from several of the "approved" certificate authorities.  The 
process some of them use to "certify" the applicant is pretty easy to spoof.  
Clearly the hackers don't see that as much of an obstacle.

-- Doug

> On 10 August 2017, at 13:41, Frank-Ulrich Sommer  wrote:
> 
> 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 still use a fake cert signed by one of those CAs. 
> Public key pinning could be an (academic) alternative and would still work 
> with a cert signed by an external CA without restrictions.
> 
> If someone tells me to add security exceptions this rings all alarm bells. 
> Users who are not experts should not get used to doing this as they soon will 
> accept everything.
> 
> Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie :
>> 
>> 
>>> On 10 August 2017, at 04:37, Alef Veld  wrote:
>>> 
>>> I completely agree (having said that I'm pretty new to all this so I
>> might be full of it). 
>>> 
>>> You should run your own CA if you have an active financial interest
>> in your company (say your the owner). No added benefit to have your
>> certificate certified by a third party, why would they care about that
>> one client). Ofcourse people would say "but ofcourse you would verify
>> your own certificate" but in that case they probably don't understand
>> how it all works.
>>> 
>>> Ofcourse once your own company grows large you run the same risk of
>> entropy (incorrect documentation or records, no trained staff, no up to
>> date procedures etc.) large companies have to deal with. Maybe if you
>> had one person working full time on it, or an automated process
>> handling things it would be more secure and reliable.
>>> 
>>> Was diginotar the Dutch company, I think I remember that one.
>>> 
>>> Sent from my iPhone
>>> 
 On 10 Aug 2017, at 08:18, Stephan von Krawczynski 
>> wrote:
 
 On Wed, 9 Aug 2017 08:39:30 -0700
 Gregory Sloop  wrote:
 
> AV> So i’m using dovecot, and i created a self signed certificate
> AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there
>> matches
> AV> my mail server.  
> 
> AV> The first time it connects in mac mail however, it says the
> AV> certificate is invalid and another server might pretend to be
>> me etc.  
> 
> AV> I then have the option of trusting it.  
> 
> AV> Is this normal behaviour? Will it always be invalid if it’s not
>> signed
> AV> by a third party?  
> 
> Yes.
> The point of a trusted CA signing your cert is that they have steps
>> to
> "verify" who you are and that you're "authorized" to issue certs
>> for the
> listed FQDNs. Without that, ANYONE could create a cert, and sign it
>> and then
> present it to people connecting to your mail server [perhaps using
>> a MITM
> style attack.] The connecting party would have no way to tell if
>> your cert
> vs the attackers cert was actually valid.
> 
> It would be like showing up at the bank and having this exchange: 
> 
> You: "Hey, I'm Jim Bob - can I take money out of his account?"
> Bank: "Do you have some ID?"
> You: "Yeah! See, I have this plastic card with my picture and name,
>> that I
> ginned up in the basement."
> 
> Now does the bank say: "Yeah, that looks fine." or do they say "You
>> know we
> really need ID [a certificate] that's authenticated and issued
>> [signed] by
> the state [third-party/trusted CA.]."
> 
> I think it's obvious that accepting your basement produced ID would
>> be a
> problem. [Even if we also admit that while the state issued ID (or
>> trusted
> CA signed certs) has some additional value, it isn't without
>> potential
> flaws, etc.]
> 
> The alternative would be to add your CA cert [the one you signed
>> the server
> cert with] to all the connecting clients as a trusted CA. This way
>> your self
> signed cert would now be "trusted."
> 
> [The details are left as an exercise to the reader. Google is your
>> friend.] 
> 
> -Greg
 
 This was exactly the global thinking - until the day DigiNotar fell.
 Since that day everybody should be aware that the true problem of a
 certificate is not its issuer, but the "trusted" third party CA.
 This could have been known way before of course by simply thinking
>> about the
 basics. Do you really 

Re: Certificate cache on iOS with sending mail

[Larry Rosenman]

Which mail client on iOS? 

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: larry...@gmail.com
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
 

On 8/10/17, 3:58 PM, "dovecot on behalf of Joseph Tam" 
 wrote:

Alef Veld writes:

>> I'm wondering if there is any cache for a certificate or something, my
>> maillog shows up something like 10 bytes read, -1.  So it returns an
>> error.  I deleted the accounts and created them again, still no go. 
>> 
>> Anyone had anything similar before?

On top of the usual mail set up problems (and it appears to be some
SSL/STARTLS port number mismatch), setting up a iPhone/MacOSX mail client
can be an exercise in frustration as cause and effect may not be
synchronous.

What can happen is that after setting up parameters, if they don't work
(owing to misconfiguration or transient network problem), your mail client
will start varying the mail parameters (port #, TLS/SSL parameters,
with/without domain, etc.) in hopes of finding something that works.
Sort of auto-discovery/auto-correction.

All of a sudden, without apparent cause, it will bump into the right
settings (which may co-incide with your original settings) and it will
start working.  Uber confusing.

I believe if you disable the "Automatically manage connection" feature, it
will make your settings fixed.  This may not be the cause of your original
problem, but at least you won't be trying to troubleshoot a moving target.

Joseph Tam 

Re: Certificate cache on iOS with sending mail

[Joseph Tam]

Alef Veld writes:


I'm wondering if there is any cache for a certificate or something, my
maillog shows up something like 10 bytes read, -1.  So it returns an
error.  I deleted the accounts and created them again, still no go. 


Anyone had anything similar before?


On top of the usual mail set up problems (and it appears to be some
SSL/STARTLS port number mismatch), setting up a iPhone/MacOSX mail client
can be an exercise in frustration as cause and effect may not be
synchronous.

What can happen is that after setting up parameters, if they don't work
(owing to misconfiguration or transient network problem), your mail client
will start varying the mail parameters (port #, TLS/SSL parameters,
with/without domain, etc.) in hopes of finding something that works.
Sort of auto-discovery/auto-correction.

All of a sudden, without apparent cause, it will bump into the right
settings (which may co-incide with your original settings) and it will
start working.  Uber confusing.

I believe if you disable the "Automatically manage connection" feature, it
will make your settings fixed.  This may not be the cause of your original
problem, but at least you won't be trying to troubleshoot a moving target.

Joseph Tam 

Re: is a self signed certificate always invalid the first time?

[Frank-Ulrich Sommer]

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 still use a fake cert signed by one of those CAs. Public 
key pinning could be an (academic) alternative and would still work with a cert 
signed by an external CA without restrictions.

If someone tells me to add security exceptions this rings all alarm bells. 
Users who are not experts should not get used to doing this as they soon will 
accept everything.

Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie :
>
>
>> On 10 August 2017, at 04:37, Alef Veld  wrote:
>> 
>> I completely agree (having said that I'm pretty new to all this so I
>might be full of it). 
>> 
>> You should run your own CA if you have an active financial interest
>in your company (say your the owner). No added benefit to have your
>certificate certified by a third party, why would they care about that
>one client). Ofcourse people would say "but ofcourse you would verify
>your own certificate" but in that case they probably don't understand
>how it all works.
>> 
>> Ofcourse once your own company grows large you run the same risk of
>entropy (incorrect documentation or records, no trained staff, no up to
>date procedures etc.) large companies have to deal with. Maybe if you
>had one person working full time on it, or an automated process
>handling things it would be more secure and reliable.
>> 
>> Was diginotar the Dutch company, I think I remember that one.
>> 
>> Sent from my iPhone
>> 
>>> On 10 Aug 2017, at 08:18, Stephan von Krawczynski 
>wrote:
>>> 
>>> On Wed, 9 Aug 2017 08:39:30 -0700
>>> Gregory Sloop  wrote:
>>> 
 AV> So i’m using dovecot, and i created a self signed certificate
 AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there
>matches
 AV> my mail server.  
 
 AV> The first time it connects in mac mail however, it says the
 AV> certificate is invalid and another server might pretend to be
>me etc.  
 
 AV> I then have the option of trusting it.  
 
 AV> Is this normal behaviour? Will it always be invalid if it’s not
>signed
 AV> by a third party?  
 
 Yes.
 The point of a trusted CA signing your cert is that they have steps
>to
 "verify" who you are and that you're "authorized" to issue certs
>for the
 listed FQDNs. Without that, ANYONE could create a cert, and sign it
>and then
 present it to people connecting to your mail server [perhaps using
>a MITM
 style attack.] The connecting party would have no way to tell if
>your cert
 vs the attackers cert was actually valid.
 
 It would be like showing up at the bank and having this exchange: 
 
 You: "Hey, I'm Jim Bob - can I take money out of his account?"
 Bank: "Do you have some ID?"
 You: "Yeah! See, I have this plastic card with my picture and name,
>that I
 ginned up in the basement."
 
 Now does the bank say: "Yeah, that looks fine." or do they say "You
>know we
 really need ID [a certificate] that's authenticated and issued
>[signed] by
 the state [third-party/trusted CA.]."
 
 I think it's obvious that accepting your basement produced ID would
>be a
 problem. [Even if we also admit that while the state issued ID (or
>trusted
 CA signed certs) has some additional value, it isn't without
>potential
 flaws, etc.]
 
 The alternative would be to add your CA cert [the one you signed
>the server
 cert with] to all the connecting clients as a trusted CA. This way
>your self
 signed cert would now be "trusted."
 
 [The details are left as an exercise to the reader. Google is your
>friend.] 
 
 -Greg
>>> 
>>> This was exactly the global thinking - until the day DigiNotar fell.
>>> Since that day everybody should be aware that the true problem of a
>>> certificate is not its issuer, but the "trusted" third party CA.
>>> This could have been known way before of course by simply thinking
>about the
>>> basics. Do you really think your certificate gets more trustworthy
>because
>>> some guys from South Africa (just an example) say it is correct,
>running a
>>> _business_? Honestly, that is just naive.
>>> It would be far better to use a self-signed certificate that can be
>checked
>>> through some instance/host set inside your domain. Because only then
>the only
>>> one being responsible and trustworthy is yourself. And that is the
>way it
>>> should be.
>>> Everything else involving third party business is just bogus.
>>> 
>>> -- 
>>> Regards,
>>> Stephan
>>> 
>
>
>If you use a self-signed certificate, your users either have to 

Re: new install on Centos 7

[Peter]

On 11/08/17 07:46, Joseph Tam wrote:
>> GhettoForge has dovecot22 packages as well which provide the latest
>> stable version of Dovecot for CentOS 6 and 7.
> 
> Or consider compiling it yourself from source.  It may be more work, but
> you get complete control over your versioning, your package dependencies,
> etc.  If a bug that affects you gets fixed on a bleeding edge version
> (or is only available as a patch), you can fix it right away rather than
> waiting for the package maintainer to catch up to it.

Or just ping me in #ghettoforge on Freenode and I'll generally get it
fixed quickly, if I haven't already seen it on the list and fixed it.

There are downsides to compiling yourself.  If you do so then you have
to monitor new releases and bugfixes and push out updates.  If you use
packages in a yum repo, even a 3rd-party one like GhettoForge, then
someone else does that for you and all you have to do is run, "yum
update" on a regular basis.


Peter

Re: new install on Centos 7

[Joseph Tam]

I currently have Postfix Dovecot MySQL on Centos 6, looking at migrating
to new server

new server is CentOS 7.3, but, the Centos repo version is

dovecotx86_64   1:2.2.10-7.el7

what is the best way to install current release Dovecot on a new server ?


GhettoForge has dovecot22 packages as well which provide the latest
stable version of Dovecot for CentOS 6 and 7.


Or consider compiling it yourself from source.  It may be more work, but
you get complete control over your versioning, your package dependencies,
etc.  If a bug that affects you gets fixed on a bleeding edge version
(or is only available as a patch), you can fix it right away rather than
waiting for the package maintainer to catch up to it.

Joseph Tam 

Re: is a self signed certificate always invalid the first time?

[Stephan von Krawczynski]

On Thu, 10 Aug 2017 07:53:16 -0700
Gregory Sloop  wrote:

> [...]
> Clearly there *are* issues with trusted CA's. But they also offer some value
> you can't get with a self-signed cert - especially to people who would
> connect to your servers, but who have no real relationship with you and thus
> no reason to have any trust for you or your certificates. [...] Cheers! -Greg

Let me drop all the rest and concentrate on this idea of yours.
You really do mean that someone not trusting the issuer of some web site is
_protected_ iff this very web uses a certificate from a trusted CA? How should
that work out?
If someone does not trust me or my certificate he should not use my web at
all. The signed-by-CA certificate will not improve the content of the web (or
other service) and therefore would be a fake security component anyway if I'd
like to harm the visitor somehow.
What kind of an argument is this?
Really, the quality of the protected service is not linked in any way to the
used certificate.

-- 
Regards,
Stephan

Re: is a self signed certificate always invalid the first time?

[Gregory Sloop]

SvK> On Wed, 9 Aug 2017 08:39:30 -0700
SvK> Gregory Sloop  wrote:

>> AV> So i’m using dovecot, and i created a self signed certificate
>> AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches
>> AV> my mail server.  

>> AV> The first time it connects in mac mail however, it says the
>> AV> certificate is invalid and another server might pretend to be me etc.  

>> AV> I then have the option of trusting it.  

>> AV> Is this normal behaviour? Will it always be invalid if it’s not signed
>> AV> by a third party?  

>> Yes.
>> The point of a trusted CA signing your cert is that they have steps to
>> "verify" who you are and that you're "authorized" to issue certs for the
>> listed FQDNs. Without that, ANYONE could create a cert, and sign it and then
>> present it to people connecting to your mail server [perhaps using a MITM
>> style attack.] The connecting party would have no way to tell if your cert
>> vs the attackers cert was actually valid.

>> It would be like showing up at the bank and having this exchange: 

>> You: "Hey, I'm Jim Bob - can I take money out of his account?"
>> Bank: "Do you have some ID?"
>> You: "Yeah! See, I have this plastic card with my picture and name, that I
>> ginned up in the basement."

>> Now does the bank say: "Yeah, that looks fine." or do they say "You know we
>> really need ID [a certificate] that's authenticated and issued [signed] by
>> the state [third-party/trusted CA.]."

>> I think it's obvious that accepting your basement produced ID would be a
>> problem. [Even if we also admit that while the state issued ID (or trusted
>> CA signed certs) has some additional value, it isn't without potential
>> flaws, etc.]

>> The alternative would be to add your CA cert [the one you signed the server
>> cert with] to all the connecting clients as a trusted CA. This way your self
>> signed cert would now be "trusted."

>> [The details are left as an exercise to the reader. Google is your friend.] 

>> -Greg

SvK> This was exactly the global thinking - until the day DigiNotar fell.
SvK> Since that day everybody should be aware that the true problem of a
SvK> certificate is not its issuer, but the "trusted" third party CA.
SvK> This could have been known way before of course by simply thinking about 
the
SvK> basics. Do you really think your certificate gets more trustworthy because
SvK> some guys from South Africa (just an example) say it is correct, running a
SvK> _business_? Honestly, that is just naive.
SvK> It would be far better to use a self-signed certificate that can be checked
SvK> through some instance/host set inside your domain. Because only then the 
only
SvK> one being responsible and trustworthy is yourself. And that is the way it
SvK> should be.
SvK> Everything else involving third party business is just bogus.

I'm really not interested in hashing out this argument - it's endless [we might 
as well discuss religion or politics too, while we're at it] - but I will 
address a couple of points.

1) You'll note that I *specifically* noted "[Even if we also admit that while 
the state issued ID (or trusted
CA signed certs) has some additional value, it isn't without potential flaws, 
etc.]"

Clearly there *are* issues with trusted CA's. But they also offer some value 
you can't get with a self-signed cert - especially to people who would connect 
to your servers, but who have no real relationship with you and thus no reason 
to have any trust for you or your certificates. 

2) Certificate revocation is a another very tricky situation where a self 
signed certificate system struggles.

So, in summary: the trusted CA's and their certificate "authentication" have 
some problems [perhaps more than some] - but also offer some benefits in spite 
of those problems. IMO, it's incredibly naive to say "would be far better to 
use a self-signed certificate..." - sure there might be some areas where it's 
better, but many others where it's not. It's not an "all good" or "all bad" 
kind of thing. As they say - the only secure computer is one encased in 
concrete at at the bottom of the deepest ocean trench, unpluged and unconnected 
- and even then I'm not completely sure. 

Everything in life and security is a trade off of one set of factors against 
another.

Cheers!
-Greg

Re: Certificate cache on iOS with sending mail

[Ralph Seichter]

On 10.08.2017 14:57, Alef Veld wrote:

> I generated a new certificate for dovecot, and ever since I have this
> weird problem that my iPhone can still receive mail but cannot send
> using that mailserver. Same for my iMac.

Mail is not sent through Dovecot, but through an MTA. Based on your
earlier messages I assume that's Postfix, and you should ask on the
Postfix mailing list. See http://www.postfix.org/DEBUG_README.html if
you want to receive an answer, folks on that ML tend to reply RTFM
otherwise.

> I'm wondering if there is any cache for a certificate or something

Apple Mail uses certificates from the macOS keychain. If you accept a
certificate, it will be stored there.

-Ralph

Re: Certificate cache on iOS with sending mail

[Alef Veld]

And it's weird because it takes a long time to send and sometimes it does get 
sent. 

Sent from my iPhone

> On 10 Aug 2017, at 13:57, Alef Veld  wrote:
> 
> So I generated a new certificate for dovecot, and ever since I have this 
> weird problem that my iPhone can still receive mail but cannot send using 
> that mailserver. Same for my iMac.
> 
> My laptop works fine still and can do both.
> Local issue you would say right.
> 
> I'm wondering if there is any cache for a certificate or something, my 
> maillog shows up something like 10 bytes read, -1. So it returns an error. I 
> deleted the accounts and created them again, still no go.
> 
> Anyone had anything similar before?
> 
> Sent from my iPhone

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

I just need my internal users to download their mail, right now it's not 
something I'm terribly worried about. I'm just glad I got it all working so far 
:-)

Once I do my apache to SSL as well I'll probably get paid certificates or one 
letsencrypt certificate for all.

Sent from my iPhone

> On 10 Aug 2017, at 12:43, Ralph Seichter  wrote:
> 
>> On 10.08.2017 09:18, Stephan von Krawczynski wrote:
>> 
>> It would be far better to use a self-signed certificate that can be
>> checked through some instance/host set inside your domain.
> 
> I have been running a CA for 15+ years, generating certificates only for
> servers I personally maintain. Since my business is too small to be able
> to afford all the steps required to have my CA trusted by Mozilla, Apple
> etc., this approach leaves me with the same problem self-signed certs
> have: How can I make third party applications like web browsers or MUAs
> trust the certs I created?
> 
> For some of my customers, I can add my CA certs (root and intermediary)
> to their keystores, so the end user does not see a thing. For other
> customers, I can hand over cert fingerprints so end users can manually
> accept the connections after checking the fingerprint (guess how many
> users actually do that).
> 
> Naturally, this does not work for publicly available services, where
> there is currently no alternative to using well-known CAs. Of course
> their certs are not technically better than my own CA's or than self-
> signed certs, and their processes are sometimes garbage, the fuckups of
> Symantec being case in point. Symantec even just sold off their whole CA
> business to DigiCert; it seems they never really recovered from
> generating fake google.com certificates two years ago:
> 
> https://security.googleblog.com/2015/09/improved-digital-certificate-security.html
> 
> To get back on topic: if the OP can live with self-signed certs, that's
> perfectly fine. If Alef needs people to be able to connect to his
> Dovecot server without verifying/confirming the certificate, a CA like
> Let's Encrypt is a better choice. As far as Postfix is concerned, there
> is hardly any reason to use a well-known CA, because opportunistic TLS
> for SMTP does not care about trust chains.
> 
> -Ralph

Certificate cache on iOS with sending mail

[Alef Veld]

So I generated a new certificate for dovecot, and ever since I have this weird 
problem that my iPhone can still receive mail but cannot send using that 
mailserver. Same for my iMac.

My laptop works fine still and can do both.
Local issue you would say right.

I'm wondering if there is any cache for a certificate or something, my maillog 
shows up something like 10 bytes read, -1. So it returns an error. I deleted 
the accounts and created them again, still no go.

Anyone had anything similar before?

Sent from my iPhone

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

On 10.08.2017 09:18, Stephan von Krawczynski wrote:

> It would be far better to use a self-signed certificate that can be
> checked through some instance/host set inside your domain.

I have been running a CA for 15+ years, generating certificates only for
servers I personally maintain. Since my business is too small to be able
to afford all the steps required to have my CA trusted by Mozilla, Apple
etc., this approach leaves me with the same problem self-signed certs
have: How can I make third party applications like web browsers or MUAs
trust the certs I created?

For some of my customers, I can add my CA certs (root and intermediary)
to their keystores, so the end user does not see a thing. For other
customers, I can hand over cert fingerprints so end users can manually
accept the connections after checking the fingerprint (guess how many
users actually do that).

Naturally, this does not work for publicly available services, where
there is currently no alternative to using well-known CAs. Of course
their certs are not technically better than my own CA's or than self-
signed certs, and their processes are sometimes garbage, the fuckups of
Symantec being case in point. Symantec even just sold off their whole CA
business to DigiCert; it seems they never really recovered from
generating fake google.com certificates two years ago:

https://security.googleblog.com/2015/09/improved-digital-certificate-security.html

To get back on topic: if the OP can live with self-signed certs, that's
perfectly fine. If Alef needs people to be able to connect to his
Dovecot server without verifying/confirming the certificate, a CA like
Let's Encrypt is a better choice. As far as Postfix is concerned, there
is hardly any reason to use a well-known CA, because opportunistic TLS
for SMTP does not care about trust chains.

-Ralph

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

I completely agree (having said that I'm pretty new to all this so I might be 
full of it). 

You should run your own CA if you have an active financial interest in your 
company (say your the owner). No added benefit to have your certificate 
certified by a third party, why would they care about that one client). 
Ofcourse people would say "but ofcourse you would verify your own certificate" 
but in that case they probably don't understand how it all works.

Ofcourse once your own company grows large you run the same risk of entropy 
(incorrect documentation or records, no trained staff, no up to date procedures 
etc.) large companies have to deal with. Maybe if you had one person working 
full time on it, or an automated process handling things it would be more 
secure and reliable.

Was diginotar the Dutch company, I think I remember that one.

Sent from my iPhone

> On 10 Aug 2017, at 08:18, Stephan von Krawczynski  wrote:
> 
> On Wed, 9 Aug 2017 08:39:30 -0700
> Gregory Sloop  wrote:
> 
>> AV> So i’m using dovecot, and i created a self signed certificate
>> AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches
>> AV> my mail server.  
>> 
>> AV> The first time it connects in mac mail however, it says the
>> AV> certificate is invalid and another server might pretend to be me etc.  
>> 
>> AV> I then have the option of trusting it.  
>> 
>> AV> Is this normal behaviour? Will it always be invalid if it’s not signed
>> AV> by a third party?  
>> 
>> Yes.
>> The point of a trusted CA signing your cert is that they have steps to
>> "verify" who you are and that you're "authorized" to issue certs for the
>> listed FQDNs. Without that, ANYONE could create a cert, and sign it and then
>> present it to people connecting to your mail server [perhaps using a MITM
>> style attack.] The connecting party would have no way to tell if your cert
>> vs the attackers cert was actually valid.
>> 
>> It would be like showing up at the bank and having this exchange: 
>> 
>> You: "Hey, I'm Jim Bob - can I take money out of his account?"
>> Bank: "Do you have some ID?"
>> You: "Yeah! See, I have this plastic card with my picture and name, that I
>> ginned up in the basement."
>> 
>> Now does the bank say: "Yeah, that looks fine." or do they say "You know we
>> really need ID [a certificate] that's authenticated and issued [signed] by
>> the state [third-party/trusted CA.]."
>> 
>> I think it's obvious that accepting your basement produced ID would be a
>> problem. [Even if we also admit that while the state issued ID (or trusted
>> CA signed certs) has some additional value, it isn't without potential
>> flaws, etc.]
>> 
>> The alternative would be to add your CA cert [the one you signed the server
>> cert with] to all the connecting clients as a trusted CA. This way your self
>> signed cert would now be "trusted."
>> 
>> [The details are left as an exercise to the reader. Google is your friend.] 
>> 
>> -Greg
> 
> This was exactly the global thinking - until the day DigiNotar fell.
> Since that day everybody should be aware that the true problem of a
> certificate is not its issuer, but the "trusted" third party CA.
> This could have been known way before of course by simply thinking about the
> basics. Do you really think your certificate gets more trustworthy because
> some guys from South Africa (just an example) say it is correct, running a
> _business_? Honestly, that is just naive.
> It would be far better to use a self-signed certificate that can be checked
> through some instance/host set inside your domain. Because only then the only
> one being responsible and trustworthy is yourself. And that is the way it
> should be.
> Everything else involving third party business is just bogus.
> 
> -- 
> Regards,
> Stephan
> 

dict client auth-worker service count not obeyed?

[Peter Mogensen]

Hi,

I've noticed that in recent dovecot versions at least since 2.2.29 and
not in 2.2.12 a dovecot auth-worker will happily issue two
Lshared/passdb... queries on the same dict socket. Not always, but
sometimes.

It used to be that the dict client always closed the socket (AFAIK)
after 1 query. But now I see 2 queries issued on the same connection.

How does this work wrt. the service_count limit of the auth worker
process being default 1 ?? Is it not obeyed?

/Peter

Re: new install on Centos 7

[Peter]

On 10/08/17 18:56, voy...@sbt.net.au wrote:
> I currently have Postfix Dovecot MySQL on Centos 6, looking at migrating
> to new server
> 
> new server is CentOS 7.3, but, the Centos repo version is
> 
> dovecotx86_64   1:2.2.10-7.el7
> 
> what is the best way to install current release Dovecot on a new server ?

Following onto your similar post on the postfix mailing list...

GhettoForge has dovecot22 packages as well which provide the latest
stable version of Dovecot for CentOS 6 and 7.


Peter

Re: is a self signed certificate always invalid the first time?

[Stephan von Krawczynski]

On Wed, 9 Aug 2017 08:39:30 -0700
Gregory Sloop  wrote:

> AV> So i’m using dovecot, and i created a self signed certificate
> AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches
> AV> my mail server.  
> 
> AV> The first time it connects in mac mail however, it says the
> AV> certificate is invalid and another server might pretend to be me etc.  
> 
> AV> I then have the option of trusting it.  
> 
> AV> Is this normal behaviour? Will it always be invalid if it’s not signed
> AV> by a third party?  
> 
> Yes.
> The point of a trusted CA signing your cert is that they have steps to
> "verify" who you are and that you're "authorized" to issue certs for the
> listed FQDNs. Without that, ANYONE could create a cert, and sign it and then
> present it to people connecting to your mail server [perhaps using a MITM
> style attack.] The connecting party would have no way to tell if your cert
> vs the attackers cert was actually valid.
> 
> It would be like showing up at the bank and having this exchange: 
> 
> You: "Hey, I'm Jim Bob - can I take money out of his account?"
> Bank: "Do you have some ID?"
> You: "Yeah! See, I have this plastic card with my picture and name, that I
> ginned up in the basement."
> 
> Now does the bank say: "Yeah, that looks fine." or do they say "You know we
> really need ID [a certificate] that's authenticated and issued [signed] by
> the state [third-party/trusted CA.]."
> 
> I think it's obvious that accepting your basement produced ID would be a
> problem. [Even if we also admit that while the state issued ID (or trusted
> CA signed certs) has some additional value, it isn't without potential
> flaws, etc.]
> 
> The alternative would be to add your CA cert [the one you signed the server
> cert with] to all the connecting clients as a trusted CA. This way your self
> signed cert would now be "trusted."
> 
> [The details are left as an exercise to the reader. Google is your friend.] 
> 
> -Greg

This was exactly the global thinking - until the day DigiNotar fell.
Since that day everybody should be aware that the true problem of a
certificate is not its issuer, but the "trusted" third party CA.
This could have been known way before of course by simply thinking about the
basics. Do you really think your certificate gets more trustworthy because
some guys from South Africa (just an example) say it is correct, running a
_business_? Honestly, that is just naive.
It would be far better to use a self-signed certificate that can be checked
through some instance/host set inside your domain. Because only then the only
one being responsible and trustworthy is yourself. And that is the way it
should be.
Everything else involving third party business is just bogus.

-- 
Regards,
Stephan

new install on Centos 7

[voytek]

I currently have Postfix Dovecot MySQL on Centos 6, looking at migrating
to new server

new server is CentOS 7.3, but, the Centos repo version is

dovecotx86_64   1:2.2.10-7.el7

what is the best way to install current release Dovecot on a new server ?

tia,

V