Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Internal SSL error after Ubuntu update

by afoken (Chancellor)
on Jan 22, 2021 at 13:04 UTC ( [id://11127268]=perlquestion: print w/replies, xml ) Need Help??

afoken has asked for the wisdom of the Perl Monks concerning the following question:

It's Friday, I've switched from developer to admin, as usual, and decided to upgrade some of our machines.

There's a script to set permissions on a Linux machine based on what can be found in an LDAP server of the Samba NT4 domain controller. Not pretty, but it is working.

After updating to Ubuntu 20.04.1 LTS, LDAP access does not work any more:

SSL connect attempt failed error:14161044:SSL routines:state_machine:i +nternal error at myscript line 23

Line 23 is:

my $ldap=Company::LDAP->new();

Company::LDAP inherits from Net::LDAP and reads all required options for Net::LDAP->new() from a global configuration file:

my $conffile='/etc/ldap.conf'; sub my_conf { state %conf; my $key=shift; unless ($conf{'.read'}++) { open my $f,'<',$conffile or die "Can't open $conffile +for reading: $!"; while (<$f>) { next if /^\#/; next if /^\s+$/; s/^\s+//; s/\s+$//; my ($k,$v)=split /\s+/,$_,2; warn "Duplicate key $k in $conffile line $.\n" + if exists $conf{$k}; $conf{$k}=$v; } close $f; my $fn=$conffile; $fn=~s/\.conf$/.secret/; open my $f2,'<',$fn or die "Can't open $fn for reading +: $!"; $conf{'.secret'}=<$f2>; chomp $conf{'.secret'}; close $f2; } return $conf{$key}; } sub new { my $proto=shift; my $uri=URI->new(my_conf('uri') // die "Missing uri in $conffi +le\n"); my $host=$uri->host(); my $scheme=$uri->scheme(); my $path=$uri->path(); my $port=$uri->port(); my %opts=( onerror => 'die', host => $host, scheme => $scheme, port => $port, timeout => my_conf('timelimit')//120, version => my_conf('ldap_version')//3, inet4 => 1, inet6 => 0, ); my $ldap=$proto->SUPER::new($host,%opts) or die "Can't connect + to $host: $@"; if ((my_conf('ssl')//'') eq 'start_tls') { %opts=(); $opts{'verify'}='none'; $opts{'cafile'}=my_conf('tls_cacertfile') // die "Miss +ing tls_cacertfile in $conffile\n"; # $opts{'capath'}=$opts{'cafile'}=~s|/[^/]+$|/|; $opts{'sslversion'}='tlsv1_1'; $ldap->start_tls(%opts); } return $ldap; }

/etc/ldap.conf is

base dc=company,dc=de uri ldap://ldap.company.de/ ldap_version 3 rootbinddn cn=ldapadmin,dc=company,dc=de timelimit 5 bind_timelimit 3 pam_password crypt ssl start_tls tls_cacertfile /etc/ssl/certs/company-cacert.pem

(plus a lot of comments)

The problematic machine is actually a copy of another machine, still running the older Ubuntu 18.04.5 LTS. That one runs exactly the same code without problems.

Google gave me tons of results, but with an SNR close to zero. I've no clue what is wrong here.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re: Internal SSL error after Ubuntu update
by Corion (Patriarch) on Jan 22, 2021 at 13:13 UTC
      Ubuntu upgraded the Perl version between 18 and 20. So most likely, you will have to reinstall/recompile all XS modules.

      Right, but I use only the system perl and a single custom non-XS Module. The package manager should have installed new binary packages for all perl modules during the upgrade.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Internal SSL error after Ubuntu update
by hippo (Bishop) on Jan 22, 2021 at 13:38 UTC

    Purely a guess, but in your shoes I would check which TLS versions the LDAP server supports and which versions your upgraded client permits. There could well be a mismatch there (although, in that case I would hope for a better error message than state_machine:internal error). Also try connecting to the server outside Perl just to confirm that it's an O/S level issue.


    🦛

      Purely a guess, but in your shoes I would check which TLS versions the LDAP server supports and which versions your upgraded client permits. There could well be a mismatch there (although, in that case I would hope for a better error message than state_machine:internal error).

      No ldap client installed on both machines, so I use openssl to see if I can connect:

      >openssl s_client -connect ldap.company.de:389 -starttls ldap CONNECTED(00000003) 140557505041728:error:1425F102:SSL routines:ssl_choose_client_version: +unsupported protocol:../ssl/statem/statem_lib.c:1941: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 93 bytes and written 346 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- >

      On the working machine:

      >openssl s_client -connect ldap.company.de:389 -starttls ldap CONNECTED(00000005) depth=0 C = DE, L = City, O = company GmbH, CN = *.company.de, emailAd +dress = system@company.de verify error:num=18:self signed certificate verify return:1 depth=0 C = DE, L = City, O = company GmbH, CN = *.company.de, emailAd +dress = system@company.de verify return:1 --- Certificate chain 0 s:C = DE, L = City, O = company GmbH, CN = *.company.de, emailAddre +ss = system@company.de i:C = DE, L = City, O = company GmbH, CN = *.company.de, emailAddre +ss = system@company.de --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=C = DE, L = City, O = company GmbH, CN = *.company.de, emailAd +dress = system@company.de issuer=C = DE, L = City, O = company GmbH, CN = *.company.de, emailAdd +ress = system@company.de --- No client certificate CA names sent --- SSL handshake has read 945 bytes and written 563 bytes Verification error: self signed certificate --- New, SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : AES256-SHA Session-ID: 3F6E48D0... Session-ID-ctx: Master-Key: 02158253D6C... PSK identity: None PSK identity hint: None SRP username: None Start Time: 1611324515 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) Extended master secret: no ---

      This starts to look more and more like an SSL issue. I don't understand why s_client gets SSL routines:ssl_choose_client_version:unsupported protocol, while perl gets SSL routines:state_machine:internal error.

      I've compared the output of openssl ciphers -v on both machines, it's identical:

      >openssl ciphers -v TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Ma +c=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/ +POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Ma +c=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM( +256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256 +) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) +Mac=AEAD ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA2 +0/POLY1305(256) Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/P +OLY1305(256) Mac=AEAD DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POL +Y1305(256) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM( +128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128 +) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) +Mac=AEAD ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) M +ac=SHA384 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac= +SHA384 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac= +SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) M +ac=SHA256 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac= +SHA256 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac= +SHA256 ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=S +HA1 ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SH +A1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SH +A1 ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=S +HA1 ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SH +A1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SH +A1 RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) +Mac=AEAD DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) +Mac=AEAD RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POL +Y1305(256) Mac=AEAD DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK Enc=CHACHA20/POL +Y1305(256) Mac=AEAD ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK Enc=CHACHA20/P +OLY1305(256) Mac=AEAD AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Ma +c=AEAD PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Ma +c=AEAD PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK Enc=CHACHA20/POLY1 +305(256) Mac=AEAD RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) +Mac=AEAD DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) +Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Ma +c=AEAD PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Ma +c=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac= +SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac= +SHA256 ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Ma +c=SHA384 ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=S +HA1 SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(256) Mac=SH +A1 SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(256) Mac=SH +A1 RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK Au=RSA Enc=AES(256) Mac= +SHA384 DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256) Mac= +SHA384 RSA-PSK-AES256-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SH +A1 DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SH +A1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SH +A1 PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SH +A384 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SH +A1 ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Ma +c=SHA256 ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=S +HA1 SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(128) Mac=SH +A1 SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(128) Mac=SH +A1 RSA-PSK-AES128-CBC-SHA256 TLSv1 Kx=RSAPSK Au=RSA Enc=AES(128) Mac= +SHA256 DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128) Mac= +SHA256 RSA-PSK-AES128-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SH +A1 DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SH +A1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SH +A1 PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SH +A256 PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SH +A1 >

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        ssl_choose_client_version:unsupported protocol

        That does suggest to me that the newest protocol version supported by the server is older than the oldest protocol permitted by the upgraded client. Given that your working client shows a negotiated TLSv1.1 that's probably the highest/newest supported by the server.

        Update: check the MinProtocol setting in the openssl config of your upgraded machine. You may have to configure it downwards towards TLSv1.1 to permit the connection.


        🦛

Re: Internal SSL error after Ubuntu update
by stevieb (Canon) on Jan 22, 2021 at 19:29 UTC
    "It's Friday, I've switched from developer to admin"

    Therein lies your mistake. Any admin that's been around even a short while knows to NEVER MAKE CHANGES ON A FRIDAY! :P

    Seriously.

      Therein lies your mistake. Any admin that's been around even a short while knows to NEVER MAKE CHANGES ON A FRIDAY! :P

      Seriously.

      Yepp, right. Also, don't release updates on fridays.

      But to be serious: We are a small team, and experience has shown that we can get away with one admin day every two weeks, plus a total of perhaps an hour per week for the little problems of the non-nerds in the team. (My boss is still amazed that the machines can mostly maintain themselves. I'm just too lazy for routine jobs.)

      I prefer to start late and go home late, so I can shut down systems on a friday afternoon usually without disturbing anyone. And if I really mess up stuff, I have two days to clean up before the systems have to be up and running again. (That never happened so far.)

      From time to time, we change larger parts of our infrastructure (new cables, new servers, changes to the electrical system, new PBX). That typically happens on a week-end in exchange for a few extra free days.

      Also, switching to "admin mode" helps getting a different perspective on development problems - like leaving the office for a short walk, but for a full eight hours.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      Thanks stevieb
      Your wisdom has solved many of my problems...the simple solution must be to not $work on Fridays

Re: Internal SSL error after Ubuntu update
by Anonymous Monk on Jan 22, 2021 at 18:36 UTC
    If this SSL is used internal-only, as you seem to imply, then you can get away with status quo for a while. But you really, really want to bring those libraries up to date just as soon as you possibly can.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11127268]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2024-03-29 07:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found