Go Back

OpenSSL

Good afternoon,

We're running Synergy 10.1.1c on AIX and Linux which requires OpenSSL 0.9.8.  I have a synergy application that calls a webservice on a secure website.  We deploy 0.9.8 OpenSSL libraries and this has been working for quite some time.  The web server that hosts this webservice was upgraded to Windows Server 2016 and our webservice call immediately began failing.  Through many trials and tribulation we discovered that Web Server 2016 requires TLS1.2.  OpenSSL 0.9.8 only supports TLS1.0. 

Since we are in the process of upgrading our development environment to Synergy 10.3.3 which requires OpenSSL 1.0.1e, This new version of OpenSSL also supports TLS1.2.  I set off to find the binaries for Red Hat Linux and AIX 6.1+.  

I found them for Red Hat:
libcrypto.so.1.0.1e
libssl.so.1.0.1e
libcrypto.so.10 -> libcrypto.so.1.0.1e  (Linked)
libssl.so.10 -> libssl.so.1.0.1e  (Linked)

I removed the 0.9.8 libraries and copied the 1.0.1e libraries.  Went to test my 10.1.1c application and it failed.  With the help of Synergex Support (Thanks Jerry!!!), we linked the 0.9.8 libraries to the 1.0.1e libraries and all went to working!!!!

So my Red Hat now has the additional links:
libcrypto.so.0.9.8 -> libcrypto.so.1.0.1e  (Linked)
libcrypto.so.4 -> libcrypto.so.1.0.1e  (Linked)
libssl.so.0.9.8 -> libssl.so.1.0.1e  (Linked)
libssl.so.4 -> libssl.so.1.0.1e  (Linked)

On to AIX ... AIX handles the OpenSSL libraries differently.  They have a single library file that contains the versioned stuff inside of it.  The files for AIX are:

libcrypto.a
libssl.a

The documentation says that the libraries contains 0.9.8 and 1.0.1.  However, I can't get my AIX 10.1.1c application to work like I did on Linux.

If I run ldd $DBLDIR/bin/httpslib.so to see what libraries it's looking for and whether or not it found them, it correctly finds my new libraries and shows that 0.9.8 is there.  However, I'm not sure that the 0.9.8 library which is combined with the 1.0.1e library inside the libcrypto.a file supports TLS1.2 and there is no way for me to "cheat" like I did on Red Hat.

Hopefully there are some UNIX gurus out there that can give me some ideas.

1 Answer
0   | Posted by Gayle Lewis to Other on 4/5/2018, 8:10 PM
Gayle Lewis
I figured it out!  Here's a hack for you!!!!

The libcrypto.a and the libssl.a files are archive files that can be manipulated with the ar command.  So here's what I did on AIX that mimicked what I did to get Red Hat working.

You can get a list of what is in the .a file by: 
$ ar -X32_64 -tv libcrypto.a                                          
rwxr-xr-x 537912/767508 3050171 Dec 05 05:33 2017 libcrypto.so        
rwxr-xr-x 537912/767508 2186744 Dec 05 05:33 2017 libcrypto.so.0.9.8  
rwxr-xr-x 537912/767508 3050171 Dec 05 05:33 2017 libcrypto.so.1.0.0  
rwxr-xr-x 537912/767508 3465319 Dec 05 05:33 2017 libcrypto64.so      
rwxr-xr-x 537912/767508 2527801 Dec 05 05:33 2017 libcrypto64.so.0.9.8
rwxr-xr-x 537912/767508 3465319 Dec 05 05:33 2017 libcrypto64.so.1.0.0

Notice that the .so and the .so.1.0.0 files are the same size for both the 32-Bit and 64-Bit.

I created a temporary folder for the .a file (tempcrypto) and copied the libcrypto.a file into the temporary folder.

You can then extract the files from the .a file by:
$ ar -X32_64 -xv libcrypto.a
x - libcrypto.so            
x - libcrypto.so.0.9.8      
x - libcrypto.so.1.0.0      
x - libcrypto64.so          
x - libcrypto64.so.0.9.8    
x - libcrypto64.so.1.0.0    

I then sum'd all of the files:
$ sum *                         
05723 18499 libcrypto.a         
46301  2979 libcrypto.so        
32710  2136 libcrypto.so.0.9.8  
46301  2979 libcrypto.so.1.0.0  
46620  3385 libcrypto64.so      
00694  2469 libcrypto64.so.0.9.8
46620  3385 libcrypto64.so.1.0.0

Look at that!!! The .so and the .so.1.0.0 are exactly the same for both 32-Bit and 64-Bit.

To mimic what I did on Linux, I copied the .so over the top of the .0.9.8 for both 32-Bit and 64-Bit and re-sum'd the files:
$ cp libcrypto.so libcrypto.so.0.9.8               
$ cp libcrypto64.so libcrypto64.so.0.9.8           
$ sum *                                            
05723 18499 libcrypto.a                            
46301  2979 libcrypto.so                           
46301  2979 libcrypto.so.0.9.8                     
46301  2979 libcrypto.so.1.0.0                     
46620  3385 libcrypto64.so                         
46620  3385 libcrypto64.so.0.9.8                   
46620  3385 libcrypto64.so.1.0.0                   

Now all of the 0.9.8 files are actually the 1.0.0 files for both 32-Bit and 64-Bit.

Now to recreate the .a library with the new stuff.  I first removed the old library so it would get recreated:
$ rm libcrypto.a                                   
$ ar -X32_64 -v -q libcrypto.a *so*                
ar: Creating an archive file libcrypto.a.          
q - libcrypto.so                                   
q - libcrypto.so.0.9.8                             
q - libcrypto.so.1.0.0                             
q - libcrypto64.so                                 
q - libcrypto64.so.0.9.8                           
q - libcrypto64.so.1.0.0                           

Verified that everything looked ok:
$ ar -X32_64 -tv libcrypto.a                                        
rwxr-xr-x     0/50    3050171 Apr 05 16:10 2018 libcrypto.so        
rwxr-xr-x     0/50    3050171 Apr 05 16:13 2018 libcrypto.so.0.9.8  
rwxr-xr-x     0/50    3050171 Apr 05 16:10 2018 libcrypto.so.1.0.0  
rwxr-xr-x     0/50    3465319 Apr 05 16:10 2018 libcrypto64.so      
rwxr-xr-x     0/50    3465319 Apr 05 16:13 2018 libcrypto64.so.0.9.8
rwxr-xr-x     0/50    3465319 Apr 05 16:10 2018 libcrypto64.so.1.0.0

I then repeated the exact same steps for libssl.a, copied the library to where it needed to be and it works under 10.1.1c with Web Server 2016  (TLS1.2) as well as the old Web Server 2012 (TLS1.0).

My next step is to take these new libraries and test them with the same app compiled/running under Synergy 10.3.3.  I'll update my findings.


 

4/5/2018, 9:23 PM   0  
Please log in to comment or answer this question.