Danny Horne writes:
> On 24/01/18 16:37, Dirk Stöcker wrote:
>> It's not sooo complicated:
>>
>> Short guide for UNIXoid systems:
>>
> After a long gap (and a recent server rebuild), I've revisited this and
> after a few false starts think I've created the CA and server
> certificates correctly u
On 24/01/18 16:37, Dirk Stöcker wrote:
> It's not sooo complicated:
>
> Short guide for UNIXoid systems:
>
After a long gap (and a recent server rebuild), I've revisited this and
after a few false starts think I've created the CA and server
certificates correctly using Dirk's instructions. On impl
On Wed, 24 Jan 2018, Harald Koch wrote:
It's not sooo complicated:
The length of your message contradicts that statement.
Well, I assumed that for people who operate a proper postfix instance 3
different command sets and creating two files is't complicated. If that
assumption is untrue an
On Wed, Jan 24, 2018, at 08:37, Dirk Stöcker wrote:
>
> It's not sooo complicated:
The length of your message contradicts that statement.
(These days I recommend https://github.com/square/certstrap because it's
easily scripted. I'm currently using it in several ansible playbooks,
for example.)
On Wed, 24 Jan 2018, Viktor Dukhovni wrote:
One one want to start with "umask 077", to avoid creating
world-readable private key files. This should not be
necessary with OpenSSL 1.1.0 and later, but older versions
(e.g. OpenSSL 1.0.2) create all output files with default
permissions, constraine
> On Jan 24, 2018, at 11:37 AM, Dirk Stöcker wrote:
>
> 1) Create a new CA (only once - it is a good idea to add a date in name, in
> case you have to change it later):
> openssl req -new -x509 -nodes -subj
> '/C=DE/ST=Germany/L=Berlin/O=Company/CN=Company Root Certificate
> 2018/emailAddres
On Wed, 24 Jan 2018, Danny Horne wrote:
On 22/01/2018 3:52 pm, Viktor Dukhovni wrote:
On Jan 22, 2018, at 10:06 AM, Danny Horne wrote:
Private CA sounds interesting, will have to read up about it
You can get away with a lot less complexity than the usual OpenSSL CA.
See, for example:
h
> On Jan 24, 2018, at 9:21 AM, Danny Horne wrote:
>
>> You can get away with a lot less complexity than the usual OpenSSL CA.
>> See, for example:
>>
>>
>> https://raw.githubusercontent.com/openssl/openssl/master/test/certs/mkcert.sh
>>
>> which creates certificates via "openssl x509 -req"
On 22/01/2018 3:52 pm, Viktor Dukhovni wrote:
>
>> On Jan 22, 2018, at 10:06 AM, Danny Horne wrote:
>>
>> Private CA sounds interesting, will have to read up about it
> You can get away with a lot less complexity than the usual OpenSSL CA.
> See, for example:
>
>
> https://raw.githubuserconten
On 22 Jan 2018, at 15:31, Viktor Dukhovni wrote:
> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster wrote:
>
>>> A "real" certificate is useful if you have customers connecting to
>>> your server as a submission service. While self-signed certs work
>>> fine for that purpose too, sometimes it's eas
> On Jan 22, 2018, at 10:06 AM, Danny Horne wrote:
>
> Private CA sounds interesting, will have to read up about it
You can get away with a lot less complexity than the usual OpenSSL CA.
See, for example:
https://raw.githubusercontent.com/openssl/openssl/master/test/certs/mkcert.sh
which
On 21/01/2018 9:35 pm, Viktor Dukhovni wrote:
>
> Indeed stick with what you've got. You could (if not intimidated by the
> logistics, but we may have more tools for you in this space soonish) also
> implement a private CA that signs your no-longer self-signed server cert.
> This makes it possible
> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster wrote:
>
>> A "real" certificate is useful if you have customers connecting to
>> your server as a submission service. While self-signed certs work
>> fine for that purpose too, sometimes it's easier to avoid talking
>> folks into how to import you
On 21 Jan 2018, at 21:47, Noel Jones wrote:
> On 1/21/2018 2:26 PM, Danny Horne wrote:
>> Hi all,
>>
>> Apologies if this has been discussed before, but currently I use
>> self-signed certificates on my Postfix servers for TLS negotiation, I'm
>> doing this mainly to keep the costs down. As far
> On Jan 21, 2018, at 4:07 PM, Danny Horne wrote:
>
> I won't ask you to expand on why wildcard certificates should be avoided
> (unless you want to).
The short version:
1. People who use wildcard certs tend to DoS themselves by breaking
every server with the shared key+certificate c
On 21/01/2018 8:47 pm, Viktor Dukhovni wrote:
>> I see wildcard SSL certificates are coming down in price, I use
>> SSL on one or two websites and am starting to consider one of these
>> to cover everything I do. Am I right in assuming a standard wildcard
>> SSL certificate will be usable on both
On 1/21/2018 2:26 PM, Danny Horne wrote:
> Hi all,
>
> Apologies if this has been discussed before, but currently I use
> self-signed certificates on my Postfix servers for TLS negotiation, I'm
> doing this mainly to keep the costs down. As far as I'm aware I don't
> have any problems sending / r
> On Jan 21, 2018, at 3:26 PM, Danny Horne wrote:
>
> Apologies if this has been discussed before, but currently I use
> self-signed certificates on my Postfix servers for TLS negotiation, I'm
> doing this mainly to keep the costs down.
The current cost of TLS certificates that chain up to bro
Hi all,
Apologies if this has been discussed before, but currently I use
self-signed certificates on my Postfix servers for TLS negotiation, I'm
doing this mainly to keep the costs down. As far as I'm aware I don't
have any problems sending / receiving email to / from the major
providers, but cou
19 matches
Mail list logo
