Project

General

Profile

Actions

tickets #139007

open

static.opensuse.org SSL problems when using openssl 1.0

Added by marcus@jet.franken.de 8 months ago. Updated 8 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Core services and virtual infrastructure
Target version:
-
Start date:
2023-11-02
Due date:
% Done:

0%

Estimated time:

Description

Hi,

When connecting to static.opensuse.org with openssl 1.0 (e.g. from SLES 12 SP5):

we get a bad chain of certs:

$ openssl s_client -connect static.opensuse.org:443
CONNECTED(00000003)
depth=1 O = Heroes internal CA, CN = Heroes internal CA Intermediate CA
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:/CN=atlas.infra.opensuse.org
   i:/O=Heroes internal CA/CN=Heroes internal CA Intermediate CA
 1 s:/O=Heroes internal CA/CN=Heroes internal CA Intermediate CA
   i:/O=Heroes internal CA/CN=Heroes internal CA Root CA
---
Server certificate

This is openssl 1.0.2p.

When using openssl-1_1 on the very same VM:

$ openssl-1_1 s_client -connect static.opensuse.org:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = static.opensuse.org

verify return:1

Certificate chain
0 s:CN = static.opensuse.org
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1

i:O = Digital Signature Trust Co., CN = DST Root CA X3

This is openssl 1.1.1d.

openssl 3 from TW also works.

Both commandline tools connect to the IPv6 address 2a07:de40:b27e:1204::10.

Do you have an idea what could cause this weird issue?

Ciao, Marcus

Actions #1

Updated by crameleon 8 months ago

  • Category set to Core services and virtual infrastructure
  • Status changed from New to In Progress
  • Assignee set to crameleon
  • Private changed from Yes to No

Hi!

Thanks for reaching out.

The first output looks like it is serving our internal certificate, which is not intended to be verifiable by clients on the internet.

I think there are two issues:

  • with old versions of OpenSSL, it is necessary to manually pass -servername:
       -servername name
           Set the TLS SNI (Server Name Indication) extension in the ClientHello message to the given value.  If
           -servername is not provided, the TLS SNI extension will be populated with the name given to -connect if
           it follows a DNS name format. If -connect is not provided either, the SNI is set to "localhost".  This
           is the default since OpenSSL 1.1.1.

-> Can you try if this helps?

  • our proxy server should not fall back to a backend using our internal certificate if a bogus request is received

-> We'll investigate it.

Cheers,
Georg

Actions #2

Updated by marcus@jet.franken.de 8 months ago

Hi,

Yes, actually that did help.

For some reason openssl 1.0.2 does not do that.

Ticket can be closed.

Ciao, MArcus
On Thu, Nov 02, 2023 at 04:37:12PM +0000, crameleon wrote:

[openSUSE Tracker]
Issue #139007 has been updated by crameleon.

Category set to Core services and virtual infrastructure
Status changed from New to In Progress
Assignee set to crameleon
Private changed from Yes to No

Hi!

Thanks for reaching out.

The first output looks like it is serving our internal certificate, which is not intended to be verifiable by clients on the internet.

I think there are two issues:

  • with old versions of OpenSSL, it is necessary to manually pass -servername:
       -servername name
           Set the TLS SNI (Server Name Indication) extension in the ClientHello message to the given value.  If
           -servername is not provided, the TLS SNI extension will be populated with the name given to -connect if
           it follows a DNS name format. If -connect is not provided either, the SNI is set to "localhost".  This
           is the default since OpenSSL 1.1.1.

Can you try if this helps?

  • our proxy server should not fall back to a backend using our internal certificate if a bogus request is received

We'll investigate it.

Cheers,
Georg


tickets #139007: static.opensuse.org SSL problems when using openssl 1.0
https://progress.opensuse.org/issues/139007#change-695516

  • Author: marcus@jet.franken.de
  • Status: In Progress
  • Priority: Normal
  • Assignee: crameleon
  • Category: Core services and virtual infrastructure

* Start date: 2023-11-02

Hi,

When connecting to static.opensuse.org with openssl 1.0 (e.g. from SLES 12 SP5):

we get a bad chain of certs:

$ openssl s_client -connect static.opensuse.org:443
CONNECTED(00000003)
depth=1 O = Heroes internal CA, CN = Heroes internal CA Intermediate CA
verify error:num=20:unable to get local issuer certificate


Certificate chain
0 s:/CN=atlas.infra.opensuse.org
i:/O=Heroes internal CA/CN=Heroes internal CA Intermediate CA
1 s:/O=Heroes internal CA/CN=Heroes internal CA Intermediate CA
i:/O=Heroes internal CA/CN=Heroes internal CA Root CA


Server certificate

This is openssl 1.0.2p.

When using openssl-1_1 on the very same VM:

$ openssl-1_1 s_client -connect static.opensuse.org:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = static.opensuse.org

verify return:1

Certificate chain
0 s:CN = static.opensuse.org
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1

i:O = Digital Signature Trust Co., CN = DST Root CA X3

This is openssl 1.1.1d.

openssl 3 from TW also works.

Both commandline tools connect to the IPv6 address 2a07:de40:b27e:1204::10.

Do you have an idea what could cause this weird issue?

Ciao, Marcus

--
You have received this notification because you either subscribed to or are involved in this discussion.
To change your notification preferences, please visit https://progress.opensuse.org/my/account.

Actions

Also available in: Atom PDF