Self-signed TLS certificates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Self-signed TLS certificates

Danny Horne
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 could that change in the future?  Could the likes of
Google start insisting on a chain of trust for mail delivery?

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 web and email servers?

Thanks for looking

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Viktor Dukhovni


> On Jan 21, 2018, at 3:26 PM, Danny Horne <[hidden email]> 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 broadly trusted
CAs is $0.  For example, from Let's Encrypt.  So cost should not be
your primary motivation.  But read on, ...

> As far as I'm aware I don't have any problems sending/receiving
> email to/from the major providers, but could that change in the
> future?  Could the likes of Google start insisting on a chain of
> trust for mail delivery?

This is rather unlikely in the near term.  No standards exist for
meaningful use of client certificates to authenticate MTA-to-MTA
email transport.  So certainly you won't need a CA issued cert to
send email, indeed most SMTP servers don't ask for your TLS client
certificate even if you're careless enough to configure one.

It is possible that at some time in the future (at least 5 or more
years out) valid certificate chains might be need to receive email,
but there no indication that this is looming.

> 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 web and email servers?

You *really* should AVOID wildcard certificates, they are a magnet
for both security and operational issues.  Get a distinct self-signed
or free CA certificate for each server.  Space out certificate rotation
in time for the different servers that provide redundancy for each service
so as to avoid a single point of failure when certificate rotation is
accidentally mishandled.

Finally, for SMTP, your best security gambit is DANE, and here self-signed
certificates are just as good or better than CA issued certificates.
You're far less likely to mess up certificate rotation when doing it
yourself than when integrating certbot and forgetting to care to
pre-stage DNS TLSA record updates (3 1 1) before obtaining a new cert
for the underlying public key.

See:

   http://www.postfix.org/TLS_README.html#client_tls_limits

   http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
   https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
 
   https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
   https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
   https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
 
   http://tools.ietf.org/html/rfc7671#section-8.1
   http://tools.ietf.org/html/rfc7671#section-8.4

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Noel Jones-2
In reply to this post by Danny Horne
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 / receiving email to / from the major
> providers, but could that change in the future?  Could the likes of
> Google start insisting on a chain of trust for mail delivery?
>

Since SMTP TLS is opportunistic best-effort, it's unlikely anyone
will reject self-signed certificates in the foreseeable future.

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 your self-signed cert.


> 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 web and email servers?

Yes, one certificate will work everywhere, but it's generally better
to limit certificates for each purpose eg. a wildcard for all your
websites, then either another wildcard or dedicated cert for your mail.

https://letsencrypt.org/ offers free short-term renewable
certificates.  There are scripts available to automate renewing
them.  If you want to move away from self-signed certs and have
limited funds, these are worth looking into.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Danny Horne
In reply to this post by Viktor Dukhovni
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 web and email servers?
> You *really* should AVOID wildcard certificates, they are a magnet
> for both security and operational issues.  Get a distinct self-signed
> or free CA certificate for each server.  Space out certificate rotation
> in time for the different servers that provide redundancy for each service
> so as to avoid a single point of failure when certificate rotation is
> accidentally mishandled.
>
> Finally, for SMTP, your best security gambit is DANE, and here self-signed
> certificates are just as good or better than CA issued certificates.
> You're far less likely to mess up certificate rotation when doing it
> yourself than when integrating certbot and forgetting to care to
> pre-stage DNS TLSA record updates (3 1 1) before obtaining a new cert
> for the underlying public key.
>
Thanks for the response Viktor,

I won't ask you to expand on why wildcard certificates should be avoided
(unless you want to).  I use DANE, so based on what you're saying,
wildcard certificates may not be cost effective for me anyway (since you
advise against using them and say self-signed is fine for email)

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Viktor Dukhovni


> On Jan 21, 2018, at 4:07 PM, Danny Horne <[hidden email]> 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 chain when incorrectly
      updating that key+certificate chain

  2.  Sharing of certificates across services enables attacks that redirect
      clients to the wrong service that happens to use the same certificate.

  3.  Sharing of certificates across services facilitates cross-protocol
      attacks (e.g. https://drownattack.com/) by exposing the same key
      material via both weak and strong protocols and implementations.

> I use DANE, so based on what you're saying,
> wildcard certificates may not be cost effective for me anyway (since you
> advise against using them and say self-signed is fine for email)

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 to publish "3 1 1" + "2 1 1" TLSA records, with
the "2 1 1" matching the key of your private CA, with that you can rotate
the server key more frequently, while keeping the CA key password protected.

As it stands your DANE implementation is fine for the next ~10 years:

  trisect.uk. IN MX 10 mail.trisect.uk. ; NoError AD=1
  trisect.uk. IN MX 20 2mail.trisect.uk. ; NoError AD=1
  _25._tcp.mail.trisect.uk. IN TLSA 3 0 1 c2a13da6b4b38a329dd2671640d24045e65acbc2e1f378436cd1b466d09fe4bf ; NoError AD=1
  mail.trisect.uk[87.98.165.212]: pass: TLSA match: depth = 0, name = mail.trisect.uk
    TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
    name = mail.trisect.uk
    depth = 0
      Issuer CommonName = mail.trisect.uk
      Issuer Organization = Trisect
      notBefore = 2017-12-06T18:19:26Z
      notAfter = 2027-12-06T18:19:26Z
      Subject CommonName = mail.trisect.uk
      Subject Organization = Trisect
      cert sha256 [matched] <- 3 0 1 c2a13da6b4b38a329dd2671640d24045e65acbc2e1f378436cd1b466d09fe4bf
      pkey sha256 [nomatch] <- 3 1 1 5f328d20ab5459373e85444b0a8614c1fd18c4aa88f900b017082de1b90946e4
  _25._tcp.2mail.trisect.uk. IN TLSA 3 0 1 d58b69ef28f0055f17e146338f9993e46d8e11154e2333b86978e28db5ddb3c6 ; NoError AD=1
  2mail.trisect.uk[94.23.165.25]: pass: TLSA match: depth = 0, name = 2mail.trisect.uk
    TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
    name = 2mail.trisect.uk
    depth = 0
      Issuer CommonName = 2mail.trisect.uk
      Issuer Organization = Trisect Networks
      notBefore = 2017-12-27T20:32:04Z
      notAfter = 2027-12-27T20:32:04Z
      Subject CommonName = 2mail.trisect.uk
      Subject Organization = Trisect Networks
      cert sha256 [matched] <- 3 0 1 d58b69ef28f0055f17e146338f9993e46d8e11154e2333b86978e28db5ddb3c6
      pkey sha256 [nomatch] <- 3 1 1 6bd7eb84836144f694600d7bebea60662f2b3d1250ed3a6d2aa4fed647211eed

And separate certificates for the two servers are more reliable,
just don't neglect to publish new TLSA records prior to replacing
the certificate of either server and do that one at a time (some
weeks apart).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

DTNX Postmaster
In reply to this post by Noel Jones-2
On 21 Jan 2018, at 21:47, Noel Jones <[hidden email]> 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 as I'm aware I don't
>> have any problems sending / receiving email to / from the major
>> providers, but could that change in the future?  Could the likes of
>> Google start insisting on a chain of trust for mail delivery?
>
> Since SMTP TLS is opportunistic best-effort, it's unlikely anyone
> will reject self-signed certificates in the foreseeable future.
>
> 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 your self-signed cert.

Sadly, there are folks who think that a certificate they cannot verify all the way up to a trusted root means that they should fall back to plain text. Mailgun is an example of this, and they are quite widely used despite this and several other problems.

We stopped using self-signed certificates on public-facing MTAs several years ago for reasons like this, and just went with a multi-domain certificate instead, since spending time to try and convince companies like this that this is not how it is supposed to work was more expensive, and mostly proved futile.


>> 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 web and email servers?
>
> Yes, one certificate will work everywhere, but it's generally better
> to limit certificates for each purpose eg. a wildcard for all your
> websites, then either another wildcard or dedicated cert for your mail.
>
> https://letsencrypt.org/ offers free short-term renewable
> certificates.  There are scripts available to automate renewing
> them.  If you want to move away from self-signed certs and have
> limited funds, these are worth looking into.

Regular DV certificates can be had for less than $10/year these days, and they can be registered for 1-3 years easily. Multi-domain certificates are also a possibility, in case you want/need more than one distinct hostname on a certificate without resorting to a wildcard, or when you need hostnames under more than one distinct domain.

For example, the following use case is not covered by a wildcard;

mx.example.com
smtp.domain.example
mail.company.example

But is supported by a multi-domain certificate. Let's Encrypt certificates are multi-domain certificates, by the way, and will support multiple distinct domains in the same manner. Just remember that reliably automating certificate issuance takes time too, and it tends to be really hard to compete with $10/year for one, or even a few certificates.

Also, whenever you deploy certificates, make sure to monitor them. For example;

openssl x509 -noout -checkend 2419200 -in /path/to/certificate-file.crt

will exit with 1 if the certificate expires within four weeks, or 28 days, meaning you can easily build a cron job that checks the validity of your certificates on a daily basis, warning you whenever you should take action. Other monitoring tasks can be set up to verify the certificate from the outside, to make sure that, if something does go wrong, you have a higher likelihood of being the first one to notice.

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Viktor Dukhovni


> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster <[hidden email]> 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 your self-signed cert.
>
> Sadly, there are folks who think that a certificate they cannot verify
> all the way up to a trusted root means that they should fall back to
> plain text. Mailgun is an example of this, and they are quite widely
> used despite this and several other problems.

My view is that if mailgun chooses to shoot itself in the foot and
considers sending in the clear more secure than unauthenticated TLS
then so be it, their problem, not mine...

Have you seen any traffic via mailgun that warrants protection from
passive monitoring?

It would be great to compile a list of systems that are broken in
this manner, and shame them all (politely) in a suitable public
forum.

Some senders still don't support TLS at all, even with a CA/B forum
CA (WebPKI) certificate on the receiving end.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Danny Horne
In reply to this post by Viktor Dukhovni
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 to publish "3 1 1" + "2 1 1" TLSA records, with
> the "2 1 1" matching the key of your private CA, with that you can rotate
> the server key more frequently, while keeping the CA key password protected.
Private CA sounds interesting, will have to read up about it
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Viktor Dukhovni


> On Jan 22, 2018, at 10:06 AM, Danny Horne <[hidden email]> 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 creates certificates via "openssl x509 -req" without all the overhead of
a stateful CA.  What you'd do differently is password-protect the CA key, and
perhaps issue certificates with a somewhat shorter lifetime than the 100 years
in that script.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

DTNX Postmaster
In reply to this post by Viktor Dukhovni
On 22 Jan 2018, at 15:31, Viktor Dukhovni <[hidden email]> wrote:

> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster <[hidden email]> 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 your self-signed cert.
>>
>> Sadly, there are folks who think that a certificate they cannot verify
>> all the way up to a trusted root means that they should fall back to
>> plain text. Mailgun is an example of this, and they are quite widely
>> used despite this and several other problems.
>
> My view is that if mailgun chooses to shoot itself in the foot and
> considers sending in the clear more secure than unauthenticated TLS
> then so be it, their problem, not mine...
>
> Have you seen any traffic via mailgun that warrants protection from
> passive monitoring?
>
> It would be great to compile a list of systems that are broken in
> this manner, and shame them all (politely) in a suitable public
> forum.
>
> Some senders still don't support TLS at all, even with a CA/B forum
> CA (WebPKI) certificate on the receiving end.

The problem is that Mailgun is used to send transactional email, which might contain sensitive data in ways that is not immediately obvious to the user. Slack used to use them, for example, including for notifications from private channels which might contain things people consider protected.

We talked to Slack at the time, explained what the problem was, difference between HTTPS and opportunistic TLS, got all the way up to the CTO, and he still got snookered by whatever Mailgun fielded as a counterargument, refused to adjust policy expect as a per-domain exception, which isn't very useful unless you're spotting it in the logs and open a ticket for it.

Which meant that using a public CA for the MTA certificate was the cheaper option, versus having to pick fights. There's simply too many startups out there that submit their transactional messages over some HTTPS API, never looking at what their deliverability looks like, or think they can 'optimise' SMTP, so if spending a little removes the problem entirely, well ... sorted.

Add to that the various pitfalls involved in managing a private CA, which we do for other purposes, and the ROI just never happens.

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Danny Horne
In reply to this post by Viktor Dukhovni
On 22/01/2018 3:52 pm, Viktor Dukhovni wrote:

>
>> On Jan 22, 2018, at 10:06 AM, Danny Horne <[hidden email]> 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 creates certificates via "openssl x509 -req" without all the overhead of
> a stateful CA.  What you'd do differently is password-protect the CA key, and
> perhaps issue certificates with a somewhat shorter lifetime than the 100 years
> in that script.
>
I'll stick with what I have for now.  Read up about creating a private
CA and it went over my head, I also couldn't figure out what input that
script needed from me
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates

Viktor Dukhovni


> On Jan 24, 2018, at 9:21 AM, Danny Horne <[hidden email]> 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" without all the overhead of
>> a stateful CA.  What you'd do differently is password-protect the CA key, and
>> perhaps issue certificates with a somewhat shorter lifetime than the 100 years
>> in that script.
>>
> I'll stick with what I have for now.  Read up about creating a private
> CA and it went over my head, I also couldn't figure out what input that
> script needed from me

It contains sample code that creates keys, root CAs, intermediate CAs,
CA-issued leaf certificates, and self-signed certificates.  It was used
to create the certificates for the OpenSSL test-suite, and is not as-is
intended to be used for other purposes, though enough knobs are likely
there to make that possible.  Usage examples can be found in:

  https://raw.githubusercontent.com/openssl/openssl/master/test/certs/setup.sh

if anyone wants to take a closer look.  That said, it sounds like the
path forward is for Postfix to add support for 2-level (private CA and
server cert, not just self-signed) certificate chains to the "postfix tls"
command.  That'll have to wait for 3.4, as 3.3 is almost done at this
point, too late to be adding new features, and in any case my cycles are
presently too limited.

--
        Viktor.

P.S.  A quick overview of mkcert.sh internals (uses some
bash-specific features):

The key() function generates RSA, DSA, ECDSA, DH or ED25519 keys
(if the output file is not already present):

  key() {
    local key=$1; shift

    local alg=rsa
    if [ -n "$OPENSSL_KEYALG" ]; then
        alg=$OPENSSL_KEYALG
    fi

    local bits=2048
    if [ -n "$OPENSSL_KEYBITS" ]; then
        bits=$OPENSSL_KEYBITS
    fi

    if [ ! -f "${key}.pem" ]; then
        args=(-algorithm "$alg")
        case $alg in
        rsa) args=("${args[@]}" -pkeyopt rsa_keygen_bits:$bits );;
        ec)  args=("${args[@]}" -pkeyopt "ec_paramgen_curve:$bits")
               args=("${args[@]}" -pkeyopt ec_param_enc:named_curve);;
        dsa)  args=(-paramfile "$bits");;
        ed25519)  ;;
        *) printf "Unsupported key algorithm: %s\n" "$alg" >&2; return 1;;
        esac
        stderr_onerror \
            openssl genpkey "${args[@]}" -out "${key}.pem"
    fi
  }

the req() function generates a certificate signing request (CSR) after
generating a key (if not already present) and list of DN components of
the form "name = value":

  req() {
    local key=$1; shift

    key "$key"
    local errs

    stderr_onerror \
        openssl req -new -"${OPENSSL_SIGALG}" -key "${key}.pem" \
            -config <(printf "string_mask=%s\n[req]\n%s\n%s\n[dn]\n" \
              "$REQMASK" "prompt = no" "distinguished_name = dn"
                      for dn in "$@"; do echo "$dn"; done)
  }

The cert() function reads a CSR from standard input and creates a
signed certificate:

  cert() {
    local cert=$1; shift
    local exts=$1; shift
    stderr_onerror \
        openssl x509 -req -"${OPENSSL_SIGALG}" -out "${cert}.pem" \
            -extfile <(printf "%s\n" "$exts") "$@"
  }

The various gen* functions, put these together to create various certificates.
Specifically genroot(), genca() and genee() create root CAs, intermediate CAs
and End-Entity certificates.  This "CA" is stateless, no record is kept of
issued certificates, so OCSP and CRLs are not possible.

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates (Minimal setup)

Dirk Stöcker
In reply to this post by Danny Horne
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 <[hidden email]> 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 creates certificates via "openssl x509 -req" without all the overhead of
>> a stateful CA.  What you'd do differently is password-protect the CA key, and
>> perhaps issue certificates with a somewhat shorter lifetime than the 100 years
>> in that script.
>>
> I'll stick with what I have for now.  Read up about creating a private
> CA and it went over my head, I also couldn't figure out what input that
> script needed from me
It's not sooo complicated:

Short guide for UNIXoid systems:

Create a directory and in there a directory "data"

create 2 files:
--- ca.config
[ ca ]
default_ca= CA_own
[ CA_own ]
dir= .
certs= ./data
new_certs_dir= ./ca.db.certs
database= ./ca.db.index
serial= ./ca.db.serial
RANDFILE= ./ca.db.rand
certificate= ./data/ca.pem
private_key= ./data/ca.key
default_days= 3653
default_crl_days= 30
default_md= sha512
preserve= no
policy= policy_anything
[ policy_anything ]
countryName= optional
stateOrProvinceName= optional
localityName= optional
organizationName= optional
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
--- end

--- ca3.config
[ ca ]
default_ca= CA_own
[ CA_own ]
dir= .
certs= ./data
new_certs_dir= ./ca.db.certs
database= ./ca.db.index
serial= ./ca.db.serial
RANDFILE= ./ca.db.rand
certificate= ./data/ca.pem
private_key= ./data/ca.key
default_days= 3653
default_crl_days= 30
default_md= sha512
preserve= no
policy= policy_anything
x509_extensions = v3_req
[ policy_anything ]
countryName= optional
stateOrProvinceName= optional
localityName= optional
organizationName= optional
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
[ v3_req ]
subjectAltName=$ENV::SUBJALTNAME
--- end

Then:

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/emailAddress=[hidden email]' -newkey rsa:4096 -sha512 -keyout data/ca.key -out data/ca.pem -extensions v3_ca -days 3653
echo -n "01" >ca.db.serial
mkdir ca.db.certs
touch ca.db.index

2) Create a new key
openssl req -nodes -days 3653 -subj '/C=DE/ST=Germany/L=Berlin/O=Company/CN=test.companyemail.de/emailAddress=[hidden email]' -newkey rsa:4096 -sha512 -keyout key.key -out key.csr

3) To sign a csr
openssl ca -config ca.config -out key.pem -infiles key.csr

4) To sign a csr with more than one name [altname] (must contain original name!):
SUBJALTNAME='DNS:test.companyemail.de,DNS:*.hallo.companyemail.de' openssl ca -config ca3.config -out key.pem -infiles key.csr

NOTE: serial number must increase always!

5) To revoke a certificate (e.g. when recreating same target, there is also an option to allow multiple certs for one domain):
openssl ca -config ca.config -revoke certs/whatever.pem

I always copy my resulting files under proper name to data directory to
keep them.

See also http://www.madboa.com/geek/openssl/#cert-self

Play around with the settings, timeouts, ... Verify the results with
"openssl x509 -text" (you wont get it all right one first try, some typos
are always there in the values (either in the specified fields or in the
domain name or ... :-)

In point 4 you also can create certs for "IP:" (instead of DNS:)
addresses.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates (Minimal setup)

Viktor Dukhovni


> On Jan 24, 2018, at 11:37 AM, Dirk Stöcker <[hidden email]> 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/emailAddress=[hidden email]' -newkey rsa:4096 -sha512 -keyout data/ca.key -out data/ca.pem -extensions v3_ca -days 3653
> echo -n "01" >ca.db.serial
> mkdir ca.db.certs
> touch ca.db.index
>
> 2) Create a new key
> openssl req -nodes -days 3653 -subj '/C=DE/ST=Germany/L=Berlin/O=Company/CN=test.companyemail.de/emailAddress=[hidden email]' -newkey rsa:4096 -sha512 -keyout key.key -out key.csr

A quick comment.

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, constrained only by the user's umask.

In addition to the umask, some of the directories involved
should probably be mode 0700.

For long-term CA keys, one would typically want to
passphrase-protect the private key (thus replace the
"-nodes" in the first command -aes128 or -aes256, and
then type the password again as needed to sign CSRs
and certificates).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates (Minimal setup)

Dirk Stöcker
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, constrained only by the user's umask.
>
> In addition to the umask, some of the directories involved
> should probably be mode 0700.
>
> For long-term CA keys, one would typically want to
> passphrase-protect the private key (thus replace the
> "-nodes" in the first command -aes128 or -aes256, and
> then type the password again as needed to sign CSRs
> and certificates).

Good advice!

I myself have all the files in a crypted filesystem with a long key,
which I only unpack/activate with loop device when needed.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates (Minimal setup)

Harald Koch-2
In reply to this post by Dirk Stöcker

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.)

-- 
Harald

Reply | Threaded
Open this post in threaded view
|

Re: Self-signed TLS certificates (Minimal setup)

Dirk Stöcker
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 world-accessible postfix probably should not be
operated, as it very likely does too much wrong for nowadays requirements.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)