tickets #139007
openstatic.opensuse.org SSL problems when using openssl 1.0
0%
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
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
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 NoHi!
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.orgverify 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 X1i: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.