Re: [dkim-milter-discuss] rsa-sha256 not available with CentOS5/RHEL5?

> I was planning on deploying dkim-milter but I noticed that after 
> compiling and installing I got the error below on the reply from 
> sa...@se....  After searches on the subject I gather that older 
> versions of OpenSSL do not support rsa-sha256.  Is this correct?
>
> (verification error: signature algorithm invalid) header.i=@sendmail.net
>
> [static@amos ~]$ dkim-filter -V
> dkim-filter: Sendmail DKIM Filter v2.1.1
>         Compiled with OpenSSL 0.9.7a Feb 19 2003
>         Supported signing algorithms:
>                 rsa-sha1
>         Supported canonicalization algorithms:
>                 relaxed
>                 simple
>
> I am just surprised that the latest version of CentOS5/RHEL5 would be 
> too outdated to use sa...@se....  I am pretty much stuck with 
> the default openssl versions for support reasons so I am wondering how 
> wide spread sha256 is used.  I know that sha1 is getting outdated and 
> has issues that make it easier to crack but it seems like a bad idea to 
> push an algorithm that some of the well known OS vendors do not support 
> by default... especially if we want dkim-milter to get used by as many 
> mail servers as we can.
>
> Or did I do something wrong and sha256 is supported with openssl 0.9.7a?
Greetings! You need openssl 0.9.8 to do sha256. I have this running in 
production on a Fedora Core 3 box, and was able to accomplish it by 
building and installing the openssl 0.9.8 libraries and header files 
into a separate directory, like /usr/openssl-0.9.8e:
./Configure -DSSL_ALLOW_ADH -DSHA256_ASM --prefix=/usr/openssl-0.9.8e 
--openssldir=/usr/openssl-0.9.8e/share/openssl linux-elf shared
make install build-shared
echo "/usr/openssl-0.9.8e/lib" >> /etc/ld.so.conf.d/openssl-0.9.8e.conf
ldconfig

The rest of your existing CentOS binaries will continue to function 
linked against 0.9.7, and you have to simply build dkim-milter to link 
against the openssl libraries in your separate directory.

APPENDDEF(`confLIBS', `-lssl -lcrypto')
APPENDDEF(`confINCDIRS', `-I/usr/openssl-0.9.8e/include')
APPENDDEF(`confLIBDIRS', `-L/usr/openssl-0.9.8e/lib')

The resulting binary should link like this:
ldd obj.Linux.2.6.12-1.1381_FC3smp.i686/dkim-filter/dkim-filter
<snip>
libssl.so.0.9.8 => /usr/openssl-0.9.8e/lib/libssl.so.0.9.8 (0x00111000)
libcrypto.so.0.9.8 => /usr/openssl-0.9.8e/lib/libcrypto.so.0.9.8 
(0x002e9000)
<snip>

And the proof is in the pudding:
dkim-filter -V
<snip>
Supported signing algorithms:
rsa-sha1
rsa-sha256
<snip>

FWIW, I have built my production verification systems to support both 
rsa-sha1 and sha256, while I am intentionally running my signing systems 
in rsa-sha1 mode for maximum backward compatibility with systems like 
your's. This is done using the -S dkim-filter parameter, or the 
SignatureAlgorithm dkim-filter.conf parameter.

I am actually curious how others are solving this problem.