Wisselende certificaten bij gebruik SSL

[sciurius]

Ik heb in WebStation enkele virtual hosts, waarvan sommige een eigen certificaat hebben.


Als ik zo'n host benader vanaf mijn LAN, dan krijg ik soms het eigen certificaat aangeboden, maar soms ook het default Synology certificaat.

Bv. vanaf mijn workstation:

Code: [Selecteer]

% echo Q | openssl s_client -connect cloud.squirrel.nl:443
CONNECTED(00000003)
depth=1 O = CAcert Inc., OU = http://www.CAcert.org, CN = CAcert Class 3 Root
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = cloud.squirrel.nl
verify return:1
---
Certificate chain
 0 s:CN = cloud.squirrel.nl
   i:O = CAcert Inc., OU = http://www.CAcert.org, CN = CAcert Class 3 Root
 1 s:O = CAcert Inc., OU = http://www.CAcert.org, CN = CAcert Class 3 Root
   i:O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing Authority, emailAddress = support@cacert.org
---

Hier ontvang ik de juiste (eigen, CAcert uitgegeven) certificaten.
Vanaf een andere server in het LAN:

Code: [Selecteer]

$ echo Q |openssl s_client -connect cloud.squirrel.nl:443
CONNECTED(00000003)
depth=0 C = TW, L = Taipei, O = Synology Inc., CN = synology.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = TW, L = Taipei, O = Synology Inc., CN = synology.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = TW, L = Taipei, O = Synology Inc., CN = synology.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=TW/L=Taipei/O=Synology Inc./CN=synology.com
   i:/C=TW/L=Taipei/O=Synology Inc./CN=Synology Inc. CA
---

Hier ontvang ik het Synology certificaat.

Iemand enig idee hoe dat kan (en hoe te verhelpen)?

[Briolet]

Het "openssl s_client" commando is hier niet geschikt voor. Ook bij veel commerciële sites  zie je niet het certificaat van de virtual host, maar het certificaat van de webserver zelf.

Voor een goede test moet je naar het certificaat in de browser zelf kijken.

Dat verklaart natuurlijk niet waarom hetzelfde commando verschillende resultaten geeft. Zijn het dezelfde openssl versies?

[sciurius]

Ja, de versies zijn verschillend:
OpenSSL 1.1.1d FIPS  10 Sep 2019
OpenSSL 1.0.1t  3 May 2016
OpenSSL 1.0.1e-fips 11 Feb 2013

Het lijkt of de 1.1.1d versie wél altijd het goede certificaat krijgt dus wellicht is het iets wat ooit verbeterd is in 1.1.1 tov. 1.0.1.

Controle met browser is niet altijd mogelijk, er zijn ook andere clients die via SSL met die (virtuele) sites praten... Gelukkig heb ik daar nog geen problemen in gezien.

[Briolet]

Op de nas staat OpenSSL 1.0.2r-fips

Op mijn mac met OS Sierra staat OpenSSL 1.0.2d

Op mijn mac met OS High Sierra heeft Apple openssl er af gegooid. Het commando is nu een hardlink naar LibreSSL 2.2.7

Ik kan zelf niet testen of versie 1.1.x het beter doet. Ik heb wel eens op 'www.nu.nl' getest. Met mijn openssl versies krijg ik alleen de melding dat er helemaal geen certificaat is. Terwijl ze die echt wel gebruiken. (Een uitgegeven door Amazon)

[sciurius]

Voor zover ik kan testen leveren alle 1.0.x connects "no peer certificate available" terwijl 1.1.x een Amazon cert krijgt.

[Briolet]

Dat bevestigt dan dat versie 1.1.x inderdaad verder kijkt bij een virtual host en niet naar het certificaat van de onderliggende server kijkt.

Uit de releasenotes van versie 1.1.1e

s_client will now send the Server Name Indication (SNI) extension by
     default unless the new "-noservername" option is used. The server name is
     based on the host provided to the "-connect" option unless overridden by
     using "-servername".

Ik denk dat oudere versies dan alleen een IP gebruiken om de informatie op te vragen en dan kan de server hem ook niet naar een specifieke virtual host sturen. Moderne browsers sturen deze info altijd mee in de header.

Edit: maar ik zie dat jij 1.1.1d gebruikte, dus juist van voor deze release. Het zal dan nog een andere aanpassing zijn.

Edit2: Het is niet de reasenote van versie 1.1.1.e, maar van alle versies tot aan 1.1.1e. Bovenstaande quite komt uit het stuk: "Changes between 1.1.0i and 1.1.1 [11 Sep 2018]". Dus al in 1.1.1 geïntroduceerd.