Question about Open SSL 1.0.2 series compatibility

[Jan Just Keijser]

Hi there,

On 07/12/2023 19:22, Fox, Shawn D (US) via openssl-users wrote:
>
> Yes the idea is to get our customers off of RHEL7, but we have to get 
> our software working on RHEL8 first.  We will have some overlap where 
> we release SW that runs on either by producing two different sets of 
> binaries.  We’ll have to wait until our customers agree that we can 
> stop building releases for RHEL7.
>
> We do link to the dynamic libraries which I didn’t mention before and  
> when we setup our execution environment we do update LD_LIBRARY_PATH.  
> I would think that would resolve conflicts as the applications would 
> then find our custom installation of openssl first. We have done 
> something similar on RHEL7 using a slightly older version than what 
> RHEL7 has installed to the system and that worked so I hoped that 
> building v1.0.2u would be possible. I’m trying to find a least common 
> denominator that will work on RHEL7 and RHEL8 until we can move on 
> from RHEL7.
>
> The function PEM_read_X509 seems to be the root my issue.  On RHEL8 it 
> doesn’t populate the out parameter the same way and it results in a 
> downstream seg fault.  I have not been able to find where that 
> function is defined.  I used grep on the openssl code and couldn’t 
> find a function definition to read.  If anyone could help me 
> understand why that is, I would appreciate it.  It doesn’t look like a 
> MACRO but perhaps it is exported from somewhere but I cannot find the 
> function implementation so that I can read the code and figure out how 
> to debug it.  I’ve built openssl with debug symbols, and I cannot step 
> into that function with ‘gnu ddd’ nor can I figure out how to navigate 
> to the function implementation.
>

FWIW:
   PEM_read_X509 comes from `include/openssl/pem.h` (in conjunction with 
`crypto/pem/pem_lib.c` and pem_x509.c):

   IMPLEMENT_PEM_rw(X509, X509, PEM_STRING_X509, X509)

resulting in
309 # define IMPLEMENT_PEM_rw(name, type, str, asn1) \
310         IMPLEMENT_PEM_read(name, type, str, asn1) \
311         IMPLEMENT_PEM_write(name, type, str, asn1)

resulting in

305 # define IMPLEMENT_PEM_read(name, type, str, asn1) \
306         IMPLEMENT_PEM_read_bio(name, type, str, asn1) \
307         IMPLEMENT_PEM_read_fp(name, type, str, asn1)

leading to

221 #  define IMPLEMENT_PEM_read_fp(name, type, str, asn1) \
222 type *PEM_read_##name(FILE *fp, type **x, pem_password_cb *cb, void *u)\
223 { \
224 return PEM_ASN1_read((d2i_of_void *)d2i_##asn1, str,fp,(void 
**)x,cb,u); \
225 }

which, as far as I can tell, results in

X509  *PEM_read_X509(FILE *fp, X509 **x, pem_password_cb *cb, void *u)\
  {
    return PEM_ASN1_read((d2i_of_void *)d2i_X509, 
PEM_STRING_X509,fp,(void **)x,cb,u); \
}

(I am sure I am missing some substitutions here).
Having said that:
- yes, you can build and link OpenSSL 1.1.1 (or OpenSSL 3+) on RHEL7 but 
*don't* try to replace system libssl.so/libcrypto.so libraries - it will 
break your RHEL support.
- yes, you can build and link the fully obsolete OpenSSL 1.0.2 on RHEL8 
but again, *don't* try to replace system libssl.so/libcrypto.so 
libraries - it will break your RHEL support.
- openssl 1.0.2 and 1.1.1. are (rather subtly) API incompatible, so 
don't mix and match
- my advice is to build and link statically using your own build of 
OpenSSL 1.1.1 - RedHat tends to apply tons of patches to OpenSSL

HTH,

JJK


> *From:*Kenneth Goldman <kgoldman at us.ibm.com>
> *Sent:* Thursday, December 7, 2023 6:07 AM
> *To:* Fox, Shawn D (US) <shawn.fox at baesystems.com>; 
> openssl-users at openssl.org
> *Subject:* RE: Question about Open SSL 1.0.2 series compatibility
>
> My understanding is that openssl does not guarantee binary 
> compatibility at major releases.
>
> A big value-add of the distros like RHEL is that they recompile 
> everything and guarantee that it all works.  Replacing with a custom 
> openssl, or any other system library, will probably break applications.
>
> I would try either static link to your old version or link to a local 
> old version, but not install openssl in the system area.
>
> The ideal solution would be to get your customers off RHEL7, which was 
> end of life 3 years ago, but you may have no choice.
>
> *From:*openssl-users <openssl-users-bounces at openssl.org> *On Behalf Of 
> *Fox, Shawn D (US) via openssl-users
> *Sent:* Wednesday, December 6, 2023 7:34 PM
> *To:* openssl-users at openssl.org
> *Subject:* [EXTERNAL] Question about Open SSL 1.0.2 series compatibility
>
> I’m supporting a project that has been using the openssl 1. 0. 0 
> series built for RHEL7 for some time now. OpenSSL 1. 1. 1 has breaking 
> API changes, so I’ve built OpenSSL 1. 0. 2u for starters in order to 
> upgrade to that version first,
>
> I’m supporting a project that has been using the openssl 1.0.0 series 
> built for RHEL7 for some time now.  OpenSSL 1.1.1 has breaking API 
> changes, so I’ve built OpenSSL 1.0.2u for starters in order to upgrade 
> to that version first, but I am building for both RHEL7 and RHEL8.  I 
> have a couple of questions that I haven’t found answers for searching 
> the web yet.
>
> Is OpenSSL 1.0.2 compatible with native apps built for RHEL8?  
> Although it might not be ideal can it work on RHEL8?  I’ve built it on 
> RHEL8 and I have used the openssl binary to read some cert files with 
> the x509 sub-command, and it seems to produce the same results on 
> RHEL7 and RHEL8 using the program from within bash shell.  That leads 
> me to believe that I should be able to link a native c++ app with 
> openssl 1.0.2u and run that on RHEL8 successfully.
>
> Is OpenSSL 1.1.1 compatible with RHEL7?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231208/a9fa7cd4/attachment.htm>