Re: doveadm: Fatal: All your namespaces have a location setting

[Aki Tuomi]

On 18.02.2017 18:49, Ben wrote:
> Hi,
>
> I am trying to migrate mail from an old server and am receiving the
> following error :
>
> doveadm(u...@example.com): Fatal: All your namespaces have a location
> setting. Only namespaces with empty location settings are converted.
> (One namespace should default to mail_location setting)
>
> I found an old thread
> (http://www.dovecot.org/list/dovecot/2012-September/068269.html) that
> referred to "location" being set.
>
> However this is not the case with me, my config reads:
> namespace inbox {
>   inbox = yes
>   location =
>   mailbox Drafts {
> special_use = \Drafts
>   }
>   mailbox Junk {
> special_use = \Junk
>   }
>   mailbox Sent {
> special_use = \Sent
>   }
>   mailbox "Sent Messages" {
> special_use = \Sent
>   }
>   mailbox Trash {
> special_use = \Trash
>   }
>   prefix =
> }
>
> My dsync conf looks as follows :
> imapc_host = old-server.example.com
> imapc_user = %u
> imapc_features = rfc822.size
> imapc_features = $imapc_features fetch-headers
> mail_prefetch_count = 20
> imapc_port = 993
> imapc_ssl = imaps
> imapc_ssl_verify = yes
>
> The command I'm calling is:
>
> sudo -u my_dovecot_user doveadm -c /etc/dovecot/dsync_config.conf -o
> mail_fsync=never backup -R -u u...@example.com imapc:

Hi!

Can you post doveconf -n

Aki

Re: Problem with Let's Encrypt Certificate

[Gedalya]

On 02/19/2017 08:39 PM, Michael A. Peters wrote:
> Every time I change the private key -
>
> A) I have to make a TLSA record for the new key 

You're actually expected to pin the CA in your TLSA record, not your own key.

https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/

https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

I had the privilege of being auto-yelled at by Viktor Dukhovni over forgetting 
to adjust my TLSA after changing certificates for SMTP. I would however prefer 
to automate the process of pushing new TLSA records, waiting out twice the TTL 
and then pushing the certificate. Going through this every time would ensure I 
have valid records every time, without having to worry about the CA key 
changing. This is on my to-do list, for SMTP, XMPP, IMAP etc.

Re: Problem with Let's Encrypt Certificate

[Michael A. Peters]

On 02/19/2017 05:39 AM, KT Walrus wrote:

That's one of the reasons I don't like Let's Encrypt, with one year certs it is 
easier to look at the certs and see what is going to expire in the coming month 
needing a new private key.


I use dehydrated (with Cloudflare DNS challenges) and as far as I know, it 
seems to generate a new private key every time.


Yeah that would be a problem for me because I implement DANE.

Every time I change the private key -

A) I have to make a TLSA record for the new key
B) I have to let that key propagate in DNS while the old cert is active. 
I use 8 hour TTL for DNS records, so that takes 16 hours (twice the TTL)

C) Then I can switch to the new key / cert in the server.

I use TLSA records for everything TLS, even dovecot - despite the fact I 
am not aware of any IMAP clients that will validate via DANE - because 
it is the right thing to do and sooner or later IMAP clients will 
support DNSSEC and DANE.


Having to do that every three months for every service I run, I really 
do not see what real world benefit I or my users would gain.

Re: Problem with Let's Encrypt Certificate

[KT Walrus]

> That's one of the reasons I don't like Let's Encrypt, with one year certs it 
> is easier to look at the certs and see what is going to expire in the coming 
> month needing a new private key.

I use dehydrated (with Cloudflare DNS challenges) and as far as I know, it 
seems to generate a new private key every time. All newly generated certs are 
generated with the timestamp in the filenames and the soft links updated to 
point to the latest timestamped files. I have 4 domains each with an average of 
70 alt names, so Let’s Encrypt is saving me money. I simply run the dehydrated 
script every week in a cron job to regenerate the certs (if there is less than 
30 days until the current cert is set to expire) and rotate in any new certs.

Of course, I run my sites using Docker and it is very easy to automate renewing 
certs. Note that I had the dehydrated script fail occasionally (mostly with 500 
Server Busy errors for the Let’s Encrypt ACME server that sometimes cause me to 
have to wait a week before the script will succeed).

Automating cert renewal and cert rotation into production using Let’s Encrypt 
and Docker is a huge win for me, and has taken the pain out of manually doing 
this once a year for each domain (and paying high fees for the privilege). And 
using the DNS-01 challenge type means that I can easily generate certs for my 
mail domain (that doesn’t have a web server). In fact, using Cloudflare DNS is 
free so even DNS for my mail domain doesn’t cost anything.

Kevin

> On Feb 19, 2017, at 2:00 AM, Michael A. Peters  wrote:
> 
> On 02/18/2017 10:24 PM, Robert L Mathews wrote:
>> On 2/17/17 1:38 PM, chaouche yacine wrote:
>> 
>>> Seems wrong to me too, Robert. If you put your private key inside
>>> your certificate, won't it be sent to the client along with it ?
>> 
>> No; any SSL software that uses the file will extract the parts it needs
>> from it and convert them to its internal format for future use. It never
>> literally sends the file contents anywhere.
>> 
>> It's common and often recommended for a PEM file to contain everything
>> needed; see, for example, the bottom section of:
>> 
>> https://www.digicert.com/ssl-support/pem-ssl-creation.htm
>> 
>> Doing this avoids the key and certificate files getting out of sync later.
>> 
> 
> I don't use Let's Encrypt but to avoid them getting out of sync, I simply put 
> a time stamp in the filename, e.g.
> 
> /etc/pki/tls/private/deviant.email-20160427.key
> /etc/pki/tls/certs/deviant.email-20160427.crt
> 
> I never re-use a private key, when a cert expires I always generate a new 
> private key with a new CSR.
> 
> That's one of the reasons I don't like Let's Encrypt, with one year certs it 
> is easier to look at the certs and see what is going to expire in the coming 
> month needing a new private key.
> 
> Let's Encrypt does 3 month certs and re-uses the private key when it 
> generates a new cert.
> 
> I'm sure it probably could be scripted to use a new private key every time 
> but then I have to have to update the TLSA record frequently (and you have to 
> have the new fingerprint TLSA record in DNS before you start using it) and 
> that would be a hassle.
> 
> I'm sure it probably could also be scripted to use a new private key every 
> fourth time, too.
> 
> But for me its just easier to have certs that last a year and I can easily 
> visually see what is going to need my action.