Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Openssl 3.0.0 (Julien ?LIE)
2. Merging tlscertfile and tlscafile to only one TLS certificate
(Julien ?LIE)
3. Re: Merging tlscertfile and tlscafile to only one TLS
certificate (Grant Taylor)
4. Re: Merging tlscertfile and tlscafile to only one TLS
certificate (Richard Kettlewell)
5. Re: Merging tlscertfile and tlscafile to only one TLS
certificate (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Sep 2021 21:41:16 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Openssl 3.0.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi The Doctor,
> Openssl 3 is out. Julien I believe you said
> we should be good to go.
I had already checked with alpha5, alpha8 and beta1 releases of OpenSSL
3.0.0 and it worked fine without any changes in INN source code.
libssl.so.3 was generated in <openssl>/lib.
I've just checked with the final release, and it appears libssl.so.3 is
now generated in <openssl>/lib64 on my system.
Yet configure does not see that, and wrongly puts in Makefile.global:
SSL_LDFLAGS = -L/home/iulius/work/openssl-3.0.0/lib
which of course breaks the build.
If manually changed to
SSL_LDFLAGS = -L/home/iulius/work/openssl-3.0.0/lib64
the build works.
So OpenSSL 3.0.0 is OK.
Russ, is there a reason why lib-pathname.m4 checks for /usr/lib32 or
/usr/lib64 only? I suggest to also add a check for /lib32 or /lib64.
With the following patch, configure correctly finds
/home/iulius/work/openssl-3.0.0/lib64
Note that I have /lib64 but not /usr/lib64 on an (old) Jessie Debian
system. Seems like newer versions have both.
--- m4/lib-pathname.m4 (r?vision 10563)
+++ m4/lib-pathname.m4 (copie de travail)
@@ -39,9 +39,9 @@
AC_DEFUN([_INN_LIB_ARCH_NAME],
[inn_lib_arch_name=lib
AC_CHECK_SIZEOF([long])
- AS_IF([test "$ac_cv_sizeof_long" -eq 4 && test -d /usr/lib32],
+ AS_IF([test "$ac_cv_sizeof_long" -eq 4 && { test -d /usr/lib32 || test
-d /lib32 ; }],
[inn_lib_arch_name=lib32],
- [AS_IF([test "$ac_cv_sizeof_long" -eq 8 && test -d /usr/lib64],
+ [AS_IF([test "$ac_cv_sizeof_long" -eq 8 && { test -d /usr/lib64 ||
test -d /lib64 ; }],
[inn_lib_arch_name=lib64])])])
dnl Set VARIABLE to -LPREFIX/lib{,32,64} or -LPREFIX/lib{,32,64}/SUFFIX as
--
Julien ?LIE
??La v?rit? pure et simple est tr?s rarement pure et jamais simple.??
(Oscar Wilde)
------------------------------
Message: 2
Date: Wed, 8 Sep 2021 22:47:25 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Merging tlscertfile and tlscafile to only one TLS certificate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
A ticket has recently been opened regarding the use of tlscertfile and
tlscafile. (Looks like it is easier to contact us via Github than Trac!)
https://github.com/InterNetNews/inn/issues/164
Currently, we have 2 files to deal with TLS certificates:
- tlscertfile, from which INN loads only one certificate (the first);
- tlscafile, from which INN loads all intermediary certificates.
Another possibility would be to only have 1 parameter, pointing to a
file containing the whole chain.
I see in the inn.conf documentation:
"Note that unlike Apache's SSLCertificateFile directive, tlscertfile
should not contain a concatenation of certificates. Instead, if you
have a certificate authority root certificate, set tlscafile to its path."
Wouldn't it be better to do the same thing as Apache? Is there a reason
for separating the certificates? (In case there is one global CA file
for the news server shared with several applications, it might make
sense to have it elsewhere so maybe that is the reason, though it seems
confusing to people.)
--
Julien ?LIE
??Quae longo tempore extenuentur corpora, lente reficere oportet.??
(Hippocrate)
------------------------------
Message: 3
Date: Wed, 8 Sep 2021 15:54:14 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: Merging tlscertfile and tlscafile to only one TLS
certificate
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 9/8/21 2:47 PM, Julien ?LIE wrote:
> Wouldn't it be better to do the same thing as Apache?
I don't think so. (See below.)
> Is there a reason for separating the certificates?
I believe there is.
To me:
- The tlscertfile is the local machine's certificate. It should
/only/ be accessed by processes on the local system. -- HIGH security.
- The tlscafile is a copy of public certificate(s) from certificate
authorities. It (they) can be accessed by anyone. -- low security.
My personal opinion is that the HIGH security and low security contents
should *NOT* be /mixed/ in the same file.
Aside: There may be some quibble room over public vs private part of
the certificate and wherever the associated key is stored. (I don't
remember off hand.) The key /definitely/ should *NOT* be co-mingled
with anything else of lesser sensitivity.
> (In case there is one global CA file for the news server shared with
> several applications, it might make sense to have it elsewhere so
> maybe that is the reason, though it seems confusing to people.)
I think it would be detrimental to security to share a common
certificate for multiple services. This was highlighted by the recent
ALPACA Attack (alpaca-attack.com).
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20210908/3bd51872/attachment-0001.bin>
------------------------------
Message: 4
Date: Wed, 8 Sep 2021 23:25:17 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Merging tlscertfile and tlscafile to only one TLS
certificate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 08/09/2021 21:47, Julien ?LIE wrote:
> Hi all,
>
> A ticket has recently been opened regarding the use of tlscertfile and
> tlscafile.? (Looks like it is easier to contact us via Github than Trac!)
> ? https://github.com/InterNetNews/inn/issues/164
>
> Currently, we have 2 files to deal with TLS certificates:
> ?- tlscertfile, from which INN loads only one certificate (the first);
> ?- tlscafile, from which INN loads all intermediary certificates.
>
> Another possibility would be to only have 1 parameter, pointing to a
> file containing the whole chain.
>
> I see in the inn.conf documentation:
> "Note that unlike Apache's SSLCertificateFile directive, tlscertfile
> should not contain a concatenation of certificates.? Instead, if you
> have a certificate authority root certificate, set tlscafile to its path."
>
> Wouldn't it be better to do the same thing as Apache?? Is there a reason
> for separating the certificates?? (In case there is one global CA file
> for the news server shared with several applications, it might make
> sense to have it elsewhere so maybe that is the reason, though it seems
> confusing to people.)
>
From the original report:
| At the moment it is not possible to use a let's encrypt generated
certificate with nnrpd for this reason.
This doesn't seem to be true. I use LetsEncrypt certificates with INN
and it works fine.
- certbot's chain.pem corresponds to INN's tlscafile
- certbot's cert.pem corresponds to INN's tlscertfile
- certbot's fullchain.pem correponds to Apache's SSLCertificateFile
Matching Apache does seem like a good idea.
ttfn/rjk
------------------------------
Message: 5
Date: Wed, 8 Sep 2021 23:27:04 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Merging tlscertfile and tlscafile to only one TLS
certificate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 08/09/2021 22:54, Grant Taylor wrote:
> On 9/8/21 2:47 PM, Julien ?LIE wrote:
>> Wouldn't it be better to do the same thing as Apache?
>
> I don't think so.? (See below.)
>
>> Is there a reason for separating the certificates?
>
> I believe there is.
>
> To me:
>
> ?- The tlscertfile is the local machine's certificate.? It should
> /only/ be accessed by processes on the local system.? --? HIGH security.
>
> ?- The tlscafile is a copy of public certificate(s) from certificate
> authorities.? It (they) can be accessed by anyone.? --? low security.
>
> My personal opinion is that the HIGH security and low security contents
> should *NOT* be /mixed/ in the same file.
They are both public data and are visible in the server certificate
message anyway.
> Aside:? There may be some quibble room over public vs private part of
> the certificate and wherever the associated key is stored.? (I don't
> remember off hand.)? The key /definitely/ should *NOT* be co-mingled
> with anything else of lesser sensitivity.
This isn't about the private key material, just the certificates.
ttfn/rjk
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 3
*******************************************
