Error 14094410 ssl

I get the following error during Authentication on Linux:

System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. 
---> Interop+OpenSsl+SslException: SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL. 
---> Interop+Crypto+OpenSslCryptographicException: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
   --- End of inner exception stack trace ---
   at Interop.OpenSsl.DoSslHandshake(SafeSslHandle context, Byte[] recvBuf, Int32 recvOffset, Int32 recvCount, Byte[]& sendBuf, Int32& sendCount)
   at System.Net.Security.SslStreamPal.HandshakeInternal(SafeFreeCredentials credential, SafeDeleteContext& context, SecurityBuffer inputBuffer, SecurityBuffer outputBuffer, SslAuthenticationOptions sslAuthenticationOptions)

I had added the certificates using the following code:

         X509Store personalStore = new X509Store(StoreName.Root, StoreLocation.CurrentUser);
            personalStore.Open(OpenFlags.ReadWrite);
            X509Certificate2Collection collection2 = new X509Certificate2Collection();

            collection2.Import("client.p12", "12345", X509KeyStorageFlags.PersistKeySet);
            Console.WriteLine("Adding certificates into trusted store");
            foreach (X509Certificate2 cert in collection2)
            {
                Console.WriteLine("Subject is: '{0}'", cert.Subject);
                Console.WriteLine("Issuer is:  '{0}'", cert.Issuer);
                personalStore.Add(cert);
            }

The error occurs during authentication and during the following call stream.AuthenticateAsClient(SERVERNAME, currentClientCerts, sslProtocol, sslCertRevocationCheck);

svmed	#1 Оставлено : 22 сентября 2020 г. 16:52:56(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 17.09.2020(UTC) Сообщений: 2 Откуда: Санкт-Петербург	Возникла следующая проблема. При попытке установить https-соединение с сервером (ИС МДЛП) возникает «ошибка рукопожатия», дословно Код: write EPROTO 10284:error:14094410: SSL routines:ssl3_read_bytes:sslv3 alert handshake failure: c:wsdepsopensslopensslsslrecordrec_layer_s3.c:1544:SSL alert number 40 Известно, что для подключения к этому сайту требуется ssl_ciphers: GOST2012-GOST8912-GOST8912 . Он реализован в CSP Крипто-ПРО, который в системе установлен; тем не менее, ошибка сохраняется. Ситуация повторяется на нескольких разных компьютерах. Чем это может быть вызвано? Может ли это быть связано с тем, что «Выбор типа CSP» на вкладке «Алгоритмы» панели управления CSP находится в положении «GOST R 34.10-2001» и не сохраняется, если её переключить на ГОСТ-2012?

Андрей *	#2 Оставлено : 22 сентября 2020 г. 17:33:59(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 11,753 Сказал «Спасибо»: 451 раз Поблагодарили: 1840 раз в 1423 постах	Здравствуйте. А используете openssl… ?
Техническую поддержку оказываем тут Наша база знаний
	WWW

two_oceans	#3 Оставлено : 23 сентября 2020 г. 5:15:36(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,598 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 388 раз в 363 постах	Автор: svmed Может ли это быть связано с тем, что «Выбор типа CSP» на вкладке «Алгоритмы» панели управления CSP находится в положении «GOST R 34.10-2001» и не сохраняется, если её переключить на ГОСТ-2012? Абсолютно дело не в этом. Все три перечисленные там криптопровайдера доступны одновременно, выбирает конкретная программа, обращающаяся к КриптоПро. Раскрывающийся список исключительно дизайнерское решение для выбора что просматриваете. Наверно многим стало бы понятнее если вместо раскрывающегося списка сделали три вкладки, но там просто нет места на 3 вкладки. Автор: svmed … GOST2012-GOST8912-GOST8912 … реализован в CSP Крипто-ПРО, который в системе установлен; тем не менее, ошибка сохраняется. Ситуация повторяется на нескольких разных компьютерах. Чем это может быть вызвано? Если используете openssl (или любые заморские решения на основе openssl / libeay32 / ssleay32 / libcrypto-1_1 / libssl-1_1), то кто Вам сказал что будет работать прямо из коробки? Это не сертифицированное решение. Для работы openssl c КриптоПро нужно добавить к openssl дополнительную библиотеку-мостик. В терминах openssl это называется engine. Для поддержки гост-2012 в openssl с помощью КриптоПро CSP библиотека engine называется «gostengy». Обратите внимание на такие моменты gostengy: 1) для работы с ней нужна версия библиотек openssl 1.1.x, c 1.0.x работать не будет. Для *nix есть специальная версия openssl от КриптоПро на случай если не хотите менять системный openssl, но надо будет указать в своей программе какой openssl использовать. Для Windows соответственно есть выбор использовать версию openssl оригинальную или специальную от КриптоПро. В любом случае, подвох в том, что половина зарубежных программ использующих https через openssl 1.0.х крашатся когда видят в конфигурации библиотеку для 1.1.x и приходится делать отдельный конфиг с гостом. 2) ключ должен быть в контейнере КриптоПро. Если конвертировали в формат openssl или генерировали ключ в openssl по тьме старых интернет-руководств, то использовать его эта библиотека не сможет. Импортировать закрытый ключ из файла или наоборот сохранить в файл не получится (в файле будет не ключ). Напротив, решения в спойлере выше смогут это сделать, но это уже не имеет отношения к КриптоПро. 3) сертификат как и при обычной работе с КриптоПро должен быть установлен в хранилище Личные с привязкой к контейнеру. Важно чтобы это было сделано для пользователя под которым запускаете openssl. 4) Поддерживаются команды openssl не все, а только принимающие параметры -engine gostengy -keyform engine (да, у пары команд openssl допустимы только -keyform pem и -keyform der, а у каких-то нельзя указать -engine — такие команды не получится использовать), но зато можно указывать вместо имени файла с ключом имя контейнера КриптоПро или отпечаток сертификата. Подробно в соседнем разделе. Отредактировано пользователем 23 сентября 2020 г. 5:39:33(UTC)  | Причина: Не указана
1 пользователь поблагодарил two_oceans за этот пост.	Андрей * оставлено 23.09.2020(UTC)

svmed	#4 Оставлено : 24 сентября 2020 г. 19:48:37(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 17.09.2020(UTC) Сообщений: 2 Откуда: Санкт-Петербург	Во-первых огромное спасибо за разъяснения, я пытаюсь разобраться с этой проблемой не первый месяц. Цитата: Если используете openssl (или любые заморские решения на основе openssl / libeay32 / ssleay32 / libcrypto-1_1 / libssl-1_1) Если быть точным, я использую для выполнения запросов node.js. Насколько я понимаю, openssl там используется. Цитата: Для работы openssl c КриптоПро нужно добавить к openssl дополнительную библиотеку-мостик. Для поддержки гост-2012 в openssl с помощью КриптоПро CSP библиотека engine называется «gostengy». Каким образом можно добавить туда эту библиотеку? При использовании node.js с OpenSSL-конфигурацией, приведённой в https://www.cryptopro.ru….aspx?g=posts&t=8544 запуск самой среды проходит нормально, но при подключении возникает аналогичная ошибка или «unsupported algorithm». Требуется что-то сделать в Крипто-про?

two_oceans	#5 Оставлено : 25 сентября 2020 г. 7:22:54(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,598 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 388 раз в 363 постах	Автор: svmed Во-первых огромное спасибо за разъяснения, я пытаюсь разобраться с этой проблемой не первый месяц. Пожалуйста. Автор: svmed Каким образом можно добавить туда эту библиотеку? При использовании node.js с OpenSSL-конфигурацией, приведённой в https://www.cryptopro.ru….aspx?g=posts&t=8544 запуск самой среды проходит нормально, но при подключении возникает аналогичная ошибка или «unsupported algorithm». Требуется что-то сделать в Крипто-про? В КриптоПро ничего не меняется. Скорее всего что-то не так с конфигурацией или просто «не та» версия openssl. Да, в определенные моменты разработчики OpenSSL что-то меняют и engine бывает за ними не успевает — так как тестирования совместимости с каждой версией нет, исправляется работа только когда об этом напишут в той теме. Потому выходит что на некоторых версиях OpenSSL не работает вообще. В итоге, надо провести диагностику несколькими командами: Код: openssl version -a позволяет определить версию на случай если «неудачная» из поддерживаемых («1.1.0″/»1.1.1») или старые («0.9.8″/»1.0.0″/»1.0.1″/»1.0.2»), которые не поддерживаются gostengy. Ключ a еще добавляет информацию, о том какие опции вкомпилированы при сборке. Например, с какой папки engine загружается если не указан в конфиге и с какой папки берется файл конфигурации. Файл конфигурации можно переопределить переменной окружения OPENSSL_CONF (на Windows для компьютера, для пользователя или конкретного экземпляра консоли). Код: openssl engine позволяет определить если gostengy загрузилась, в норме должно выдать что-то вроде Код: (rdrand) Intel RDRAND engine (dynamic) Dynamic engine loading support (gostengy) CryptoPro GostEngy ($Revision: 185515 $) если строки с gostengy нет — библиотека не загрузилась автоматически, но если нет ошибок, возможно будет работать «в ручном режиме» (хотя для Вашей задачи наверно нужен именно автоматический). Там может быть ошибка что библиотека не найдена — тогда править конфиг на то место, где реально лежит скачанная/установленная пакетом библиотека. Если есть ошибка с «version incompatibility» это признак что версия OpenSSL неправильная. Код: Error configuring OpenSSL 140449351493264:error:260B6091:engine routines:DYNAMIC_LOAD:version incompatibility:eng_dyn.c:507: 140449351493264:error:260BC066:engine routines:INT_ENGINE_CONFIGURE:engine configuration error:eng_cnf.c:191:section=gost_section, name=dynamic_path, value=/opt/cprocsp/cp-openssl-1.1.0/lib/amd64/engines/libgostengy.so 140449351493264:error:0E07606D:configuration file routines:MODULE_RUN:module initialization error:conf_mod.c:223:module=engines, value=engine_section, retcode=-1 Если ошибки нет, то еще вариант выполнить команду с ручной загрузкой вроде просмотра сертификата Код: openssl x509 -engine gostengy -text -nocert -in 1.cer -inform DER интересует наличие строки в самом начале Код: engine "gostengy" set. Если строка есть, то ручная загрузка библиотеки успешна. Код: openssl ciphers из вывода этой команды можно узнать загружены ли алгоритмы со словом GOST. Имеет смысл только если библиотека загрузилась автоматом, так как здесь engine указать нельзя. на Windows для поиска подстроки дописывается в конце findstr, на *nix grep. Еще есть команда замены двоеточия на переводы строки, но так сразу не вспомню. Код: openssl ciphers | findstr GOST С конфигурацией на Windows, например, очень часто приходится использовать экранирование в пути вроде D:\Others2\engines\gostengy.dll А на *nix вместо dll расширение so, и переносить собранную библиотеку «на другую сторону» нельзя. Это особенности операционной системы и реализации OpenSSL для конкретной операционной системы, которые предполагается уже известны настройщику (который по идее должен собрать OpenSSL из исходников). Ну а если скачаны откуда-то, то приходится на ощупь подбирать чего там сборщик заложил. Вот только честно я не знаю, как вызвать openssl который в node.js, если там реализация через библиотеки OpenSSL еще очень важно как их инициализуете, так как engine может не загрузиться или не добавить алгоритмы в список доступных из-за этого.

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

To monitor Citrix from a user endpoint view (=simulating a real user login), we are using Simon Lauger’s check_netscaler_gateway monitoring plugin. This has been working very well for the last couple of years — until the plugin started to return a failure one day:

ckadm@mintp ~ $ ./check_netscaler_gateway.pl -H citrix.example.com -u user -p secret -S STORE_ID
NetScaler Gateway CRITICAL — request to https://citrix.example.com/Citrix/STORE_IDWeb/cgi/login failed with HTTP 500

By using the additional -d parameter (for debug), the real reason why the plugin fails is showing:

The relevant part, highlighted in bold, shows a protocol problem (handshake problems error). 

But why would a working code suddenly stop working from one day to another? It turns out that on that particular day the plugin started to report CRITICAL, the SSL/TLS versions on the Citrix Netscaler were adjusted. The old SSLv3, TLS1.0 and TLS1.1 protocols were disabled and only TLS1.2 is now accepted. From a security point of view this makes total sense of course — but how can the plugin be fixed?

Comparing different OS

As the error message hints to a problem in Perl’s LWP module, the first guess was that an outdated version of LWP was being used. But when the very same monitoring plugin was executed on a slightly newer OS (Debian Stretch), the plugin ran just fine. A quick comparison between the different package versions revealed that it cannot be a problem of LWP:

Clearly LWP is the exact same version, however OpenSSL and the Perl module SSLeay (Perl extension for using OpenSSL) differ a lot!

It’s not the Perl script, it’s SSLeay (openssl)

When the plugin / Perl script is executed, SSLeay (basically Openssl) is used in the background. This can be seen with strace, here on Ubuntu xenial:

stat(«/etc/perl/Net/SSLeay.pmc», 0x7fff6be9cd90) = -1 ENOENT (No such file or directory)
stat(«/etc/perl/Net/SSLeay.pm», 0x7fff6be9ccc0) = -1 ENOENT (No such file or directory)
stat(«/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/Net/SSLeay.pmc», 0x7fff6be9cd90) = -1 ENOENT (No such file or directory)
stat(«/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/Net/SSLeay.pm», 0x7fff6be9ccc0) = -1 ENOENT (No such file or directory)
stat(«/usr/local/share/perl/5.22.1/Net/SSLeay.pmc», 0x7fff6be9cd90) = -1 ENOENT (No such file or directory)
stat(«/usr/local/share/perl/5.22.1/Net/SSLeay.pm», 0x7fff6be9ccc0) = -1 ENOENT (No such file or directory)
stat(«/usr/lib/x86_64-linux-gnu/perl5/5.22/Net/SSLeay.pmc», 0x7fff6be9cd90) = -1 ENOENT (No such file or directory)
stat(«/usr/lib/x86_64-linux-gnu/perl5/5.22/Net/SSLeay.pm», {st_mode=S_IFREG|0644, st_size=52995, …}) = 0
open(«/usr/lib/x86_64-linux-gnu/perl5/5.22/Net/SSLeay.pm», O_RDONLY) = 4
ioctl(4, TCGETS, 0x7fff6be9ca70)        = -1 ENOTTY (Inappropriate ioctl for device)
lseek(4, 0, SEEK_CUR)                   = 0
read(4, «# Net::SSLeay.pm — Perl module f»…, 8192) = 8192

… and later:

read(4, «# Copyright (c) 1997-2007 Graham»…, 8192) = 1324
lseek(4, 1323, SEEK_SET)                = 1323
lseek(4, 0, SEEK_CUR)                   = 1323
close(4)                                = 0
getuid()                                = 901
geteuid()                               = 901
getgid()                                = 901
getegid()                               = 901
read(3, «rust path by default, RT#104759n»…, 8192) = 8192
brk(0x27b3000)                          = 0x27b3000
getuid()                                = 901
geteuid()                               = 901
getgid()                                = 901
getegid()                               = 901
read(3, «::INET works.  All configuration»…, 8192) = 8192
brk(0x27d4000)                          = 0x27d4000
read(3, «opened’} = -1;ntt$DEBUG>=1 && DE»…, 8192) = 8192
brk(0x27f5000)                          = 0x27f5000
brk(0x2816000)                          = 0x2816000
read(3, «al_ssl_error();nt}n    }nn    $D»…, 8192) = 8192
brk(0x2837000)                          = 0x2837000
read(3, «ningfulntt    last;ntt}nntt# ini»…, 8192) = 8192
brk(0x285b000)                          = 0x285b000
read(3, »         => 1,nt},n    );nn    f»…, 8192) = 8192
brk(0x287e000)                          = 0x287e000
read(3, «ertificate failed becausen# host»…, 8192) = 8192
brk(0x28a0000)                          = 0x28a0000
brk(0x28c1000)                          = 0x28c1000

Comparing this to the strace outpout on Debian stretch:

stat(«/etc/perl/Net/SSLeay.pmc», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/etc/perl/Net/SSLeay.pm», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/usr/local/lib/x86_64-linux-gnu/perl/5.24.1/Net/SSLeay.pmc», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/usr/local/lib/x86_64-linux-gnu/perl/5.24.1/Net/SSLeay.pm», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/usr/local/share/perl/5.24.1/Net/SSLeay.pmc», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/usr/local/share/perl/5.24.1/Net/SSLeay.pm», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/usr/lib/x86_64-linux-gnu/perl5/5.24/Net/SSLeay.pmc», 0x7ffdbbb7d080) = -1 ENOENT (No such file or directory)
stat(«/usr/lib/x86_64-linux-gnu/perl5/5.24/Net/SSLeay.pm», {st_mode=S_IFREG|0644, st_size=52995, …}) = 0
open(«/usr/lib/x86_64-linux-gnu/perl5/5.24/Net/SSLeay.pm», O_RDONLY) = 4
ioctl(4, TCGETS, 0x7ffdbbb7ce50)        = -1 ENOTTY (Inappropriate ioctl for device)
lseek(4, 0, SEEK_CUR)                   = 0
read(4, «# Net::SSLeay.pm — Perl module f»…, 8192) = 8192

And later:

read(4, «# Copyright (c) 1997-2007 Graham»…, 8192) = 1410
lseek(4, 1409, SEEK_SET)                = 1409
lseek(4, 0, SEEK_CUR)                   = 1409
close(4)                                = 0
getuid()                                = 0
geteuid()                               = 0
getgid()                                = 0
getegid()                               = 0
read(3, «all_digests();ntNet::SSLeay::ran»…, 8192) = 8192
brk(0x55c3c5c37000)                     = 0x55c3c5c37000
getuid()                                = 0
geteuid()                               = 0
getgid()                                = 0
getegid()                               = 0
read(3, «NSSL_DIR. Unfortunately it is no»…, 8192) = 8192
brk(0x55c3c5c58000)                     = 0x55c3c5c58000
brk(0x55c3c5c57000)                     = 0x55c3c5c57000
read(3, «->{PeerAddr} || $arg_hash->{Peer»…, 8192) = 8192
brk(0x55c3c5c7a000)                     = 0x55c3c5c7a000
read(3, «nt$SSL_OBJECT{$ssl} = [$socket,1″…, 8192) = 8192
brk(0x55c3c5c9b000)                     = 0x55c3c5c9b000
read(3, «et::SSLeay::peek($ssl,1);ntif ( «…, 8192) = 8192
brk(0x55c3c5cbc000)                     = 0x55c3c5cbc000
brk(0x55c3c5cdd000)                     = 0x55c3c5cdd000
read(3, «} else {n    *peer_certificates «…, 8192) = 8192
brk(0x55c3c5cfe000)                     = 0x55c3c5cfe000
read(3, «my ($self,$algo,$cert,$key_only)»…, 8192) = 8192
brk(0x55c3c5d1f000)                     = 0x55c3c5d1f000
brk(0x55c3c5d40000)                     = 0x55c3c5d40000
brk(0x55c3c5d3f000)                     = 0x55c3c5d3f000
read(3, «eaken($handle);n    bless \$hand»…, 8192) = 8192
brk(0x55c3c5d60000)                     = 0x55c3c5d60000
read(3, «least onent# buffer was written «…, 8192) = 8192
brk(0x55c3c5d82000)                     = 0x55c3c5d82000
read(3, «eds Net::SSLeay>=1.56 and OpenSS»…, 8192) = 8192
brk(0x55c3c5da3000)                     = 0x55c3c5da3000
brk(0x55c3c5da2000)                     = 0x55c3c5da2000
brk(0x55c3c5dc4000)                     = 0x55c3c5dc4000
read(3, «lsext_status_cb($ctx,undef);nt  «…, 8192) = 8192
brk(0x55c3c5de5000)                     = 0x55c3c5de5000
brk(0x55c3c5de4000)                     = 0x55c3c5de4000
read(3, «=2 && DEBUG(«$uri just answered «…, 8192) = 1671
brk(0x55c3c5e05000)                     = 0x55c3c5e05000
close(3)                                = 0

On Debian 9 no al_ssl_error occurred.

How to solve this now?

Obviously the cleanest way is to upgrade the already outdated Operating System (Ubuntu 16.04/xenial). This release will be end of life in April 2021 and should be updated. This way the newer OpenSSL and SSLeay versions will be installed which include compatibility changes for updated protocols and ciphers.

If the OS cannot be upgraded (for whatever reason), the Net::SSLeay Perl module and the openssl libraries should be manually upgraded. See the steps below.

Compiling and installing newer OpenSSL

Installing a new version of the Net::SSLeay Perl module using cpan is not enough as it compiles against the already installed OpenSSL libraries (1.0.2g in this case). The same SSL protocol/handshake error would still happen. So first, a new OpenSSL version needs to be downloaded and compiled. It doesn’t have to replace the existing openssl version on that machine but the libraries are required.

First download a recent version of OpenSSL (here 1.1.1h):

ckadm@mintp ~/build $ wget https://www.openssl.org/source/openssl-1.1.1h.tar.gz
ckadm@mintp ~/build $ tar -xzf openssl-1.1.1h.tar.gz
ckadm@mintp ~/build $ cd openssl-1.1.1h/

Then create a target directory for the new OpenSSL libraries (default target directory would be /usr/local/lib):

ckadm@mintp ~/build/openssl-1.1.1h $ mkdir ~/build/openssl

This path (/home/ckadm/build/openssl) can now be used as prefix:

ckadm@mintp ~/build/openssl-1.1.1h $ ./config —prefix=/home/ckadm/build/openssl
ckadm@mintp ~/build/openssl-1.1.1h $ make -j24
ckadm@mintp ~/build/openssl-1.1.1h $ make install

Usually this all should work fine and you should have the following directories the target path:

ckadm@mintp ~/build/openssl-1.1.1h $ ll /home/ckadm/build/openssl
total 28
drwxrwxr-x 7 ckadm ckadm 4096 Nov  2 13:27 ./
drwxrwxr-x 4 ckadm ckadm 4096 Nov  2 13:25 ../
drwxrwxr-x 2 ckadm ckadm 4096 Nov  2 13:27 bin/
drwxrwxr-x 3 ckadm ckadm 4096 Nov  2 13:27 include/
drwxrwxr-x 4 ckadm ckadm 4096 Nov  2 13:27 lib/
drwxrwxr-x 4 ckadm ckadm 4096 Nov  2 13:28 share/
drwxrwxr-x 5 ckadm ckadm 4096 Nov  2 13:27 ssl/

Compiling and installing newer Net::SSLeay module

The current version of Net::SSLeay (1.88 as of this writing) can easily be downloaded using cpan:

cpan[1]> get Net::SSLeay
cpan[2]> quit

This should download and extract the current release in a .cpan directory.

Note: As an alternative, the release can also be manually downloaded from meta::cpan.

After changing into the source code directory created by cpan, the magic key is to set an environment variable OPENSSL_PREFIX which points to the newer OpenSSL version, followed by perl Makefile.PL.

mintp ~ # cd .cpan/build/Net-SSLeay-1.88-c7vzSa/
mintp Net-SSLeay-1.88-c7vzSa # OPENSSL_PREFIX=/home/ckadm/build/openssl perl Makefile.PL
Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n]
*** Found OpenSSL-1.1.1h installed in /home/ckadm/build/openssl
*** Be sure to use the same compiler and options to compile your OpenSSL, perl,
    and Net::SSLeay. Mixing and matching compilers is not supported.
Checking if your kit is complete…
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::SSLeay
Writing MYMETA.yml and MYMETA.json

The output already mentions it: OpenSSL 1.1.1h was found.

Now the module can be built and installed (as root — or run sudo make install):

mintp Net-SSLeay-1.88-c7vzSa # make
mintp Net-SSLeay-1.88-c7vzSa # make install
Running Mkbootstrap for Net::SSLeay ()
chmod 644 «SSLeay.bs»
Manifying 2 pod documents
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /usr/local/lib/x86_64-linux-gnu/perl/5.22.1/auto/Net/SSLeay/SSLeay.so
Appending installation info to /usr/local/lib/x86_64-linux-gnu/perl/5.22.1/perllocal.pod

Testing and running the plugin again

Now that the newer Net::SSLeay Perl module was installed (with root privileges) into /usr/local… (which should be part of $PATH), Perl should automatically detect the newer module:

ckadm@mintp ~ $ perl -MNet::SSLeay -le ‘print $Net::SSLeay::VERSION’
1.88

So far so good. What about the Perl script, the monitoring plugin check_netscaler_gateway?

ckadm@mintp ~ $ ./check_netscaler_gateway.pl -H citrix.example.com -u user -p secret -S STORE_ID
NetScaler Gateway OK — DESKTOP; Desktop MCP; Desktop Media; Desktop-MCP;

Great! It works again!

TL;DR

Handling https and its protocols has changed a lot in recent years. This is not always obvious. But it becomes a problem when older OpenSSL libraries are used in programs and scripts. A distribution upgrade is often the easiest way to make sure newer ssl/tls protocols and ciphers are accepted. However it is also possible to manually compile and upgrade programs with the newer libraries.

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.