Nginx setup SSL issue - MER-CRY-PUB-00075

[Mike521w]

We have a self-hosted Miva site that we're switching from Apache to Nginx. Our host set up a dev site running Nginx for us and we have Miva running correctly, thanks to the help we received in this thread: https://www.miva.com/forums/forum/on...iguration-file

One problem I'm having is that when I try to create a new customer account in the Miva admin, I get this fatal error:

Error Code: MER-CRY-PUB-00075
Description: Unable to load SSL routine SSLeay

I checked with our host and they confirmed that the new server has SSLeay module, but for some reason we can't tell Miva how to see / use it.

Anyone have any ideas?

[ILoveHostasaurus]

This isn't an issue related to the web server software. Was the site working before the change? I believe that issue is more in the Empresa config related to crypto / ssl libraries. Does diagtool show anything useful?

[Mike521w]

hmm after reading your post I checked our mivavm.conf file and noticed these lines:

openssl=/usr/lib64/libssl.so.1.0.0d
openssl_crypto=/usr/lib64/libcrypto.so.1.0.0d

So I checked and that file doesn't exist on the nginx server - instead we have /usr/lib64/libcrypto.so.1.0.0e - so I made this update:

openssl=/usr/lib64/libssl.so.1.0.0e
openssl_crypto=/usr/lib64/libcrypto.so.1.0.0e

Then I killed mivavm and restarted it:

runuser -l content -c 'spawn-fcgi -p 8005 -n -- /var/www/sites/www.example.com/cgi-bin/mivavm &'

But still getting the same error to my surprise.. Maybe this info is helpful from the System Variables page of diagtool:

s.miva_sslavailable:    0
file_ca=/etc/ssl/certs/ca-bundle.crt
ssl_crypto=/usr/lib64/libcrypto.so.1.0.0e
ssl_openssl=/usr/lib64/libssl.so.1.0.0e
ssl_sni=-1

Other tests etc from diagtool are all passes..

The apache site was (and still is) running ok, we haven't switched over to nginx yet

[Mike521w]

Problem is fixed, I misread the 1s and 0s in the file names. I entered this into mivavm.conf:

openssl=/usr/lib64/libssl.so.1.0.0e
openssl_crypto=/usr/lib64/libcrypto.so.1.0.0e

But I should have had:

openssl=/usr/lib64/libssl.so.1.0.1e
openssl_crypto=/usr/lib64/libcrypto.so.1.0.1e

Corrected the entries, uploaded the conf file, killed mivavm and restarted it and all is good.

[ILoveHostasaurus]

Ah very good, that was actually going to be my next question because 1.0.0 can't do TLS 1.2 which I thought may end up impacting you if you use a payment gateway even if we did get it figured out. :-)

[Mike521w]

Yea I go a little cross-eyed when looking at all those 1s and 0s and dots lol

One more issue for you if you don't mind, rather than creating another thread. The next thing for me to do would be re-encrypt everything (the merchdb.dat file is plain text at the moment). So I went to the PA-DSS Checklist and saw a fatal error at the bottom:

Error Code:    MER-DBP-CRY-00015
Description:    mysql_stmt_prepare: Table 'miva.s01_PrivateKeys' doesn't exist

This already seemed weird because the DB on the nginx site started as a straight copy of the DB on the live site, so how could one table be missing right? But anyway I figured I'd just use PHPMyAdmin to dump a copy of the s01_PivateKeys table from the live site and import it into the nginx site - but it turns out that table doesn't exist on the live site. And even weirder - when I visit the PA-DSS Checklist on the live site, it doesn't give the fatal error. There are other issues as far as pass/fail, but no fatal error..

I looked at the source code in the 9.07.03 LSK and I see the code to create the s01_PivateKeys table, so technically I could just use PHPMyAdmin and manually create an empty one and set up the structure, but I have a feeling this is a bad idea.

[ILoveHostasaurus]

The private key data is referenced separately in the merchdb.dat file and can be in the same database the store uses, a different one (on a different host as well), or dbase file. Perhaps you have a second database named 'miva' that the other store uses for the key data? Or the entire mivadata directory wasn't replicated and a dbase database file collection didn't come over?

[Mike521w]

That was it - I'd removed the merchdb.dat file's reference to mm5_privatekey.dbf on the nginx server, and I forgot about it. I forget why I even removed it - I think I was just trying to get the DB connection working and I wanted the file as simple as possible. Anyway, I added it back and was able to go through encryption without a problem.

Looking like we should be able to switch to this server pretty soon now. Thank you again!