On Sun, Nov 25, 2012 at 04:15:41PM +0000, Viktor Dukhovni wrote:
> > > When I run this and check the contents of the smtpd.pem file (did
> > > you ever look at the file contents? Why not?) I see:
> >
> > > $ egrep '^-----' smtpd.pem
> > > -----BEGIN PRIVATE KEY-----
> > > -----END PRIVATE KEY-----
> > > -----BEGIN CERTIFICATE-----
> > > -----END CERTIFICATE-----
> >
> > It was:
> >
> > -----BEGIN CERTIFICATE-----
> > -----END CERTIFICATE-----
> > -----END PRIVATE KEY-----
>
> So the output was overlapped, which is different than what I see
> (but I only tested OpenSSL 1.0.x on BSD-like systems). Thus it is
> safer to generate the key and cert in separate command invocations.
For the record, this is brain-damage in linux /dev/fd semantics.
On BSD-like systems and Solaris opening /dev/fd/<number> is equivalent
to calling dup(<number>) and returns a second file descriptor for the
same file:
- The file offset (i.e. open file table slot) is shared
between the original and new descriptor, consecutive
writes on either descriptor are concatentated, and don't
clobber each other.
- Since no new file is opened, the two files are open with
the same mode and no additional permission checks are applied
when opening /dev/fd.
Both of the above are false with Linux. Thus you can EPERM openining
/dev/stdout or /dev/fd/<number> and writes to /dev/stdout followed
by writes to the original standard output do clobber each other unless
one opens stdout with O_APPEND. I consider the Linux semantics broken,
but perhaps I am missing an important design consideration that makes
the Linux semantics correct.
So my one-shot recipe can be adjusted as follows:
tmp=$(mktemp smtpd.pem.XXXXXX)
openssl req -new -x509 -newkey rsa:1280 -nodes -keyout /dev/stdout \
-days $((356 * 10)) -subj "/CN=$(uname -N)" >> "$tmp"
mv "$tmp" smtpd.pem
but this is perhaps over-optimization, and two steps are just fine.
--
Viktor.
