Expiration of DST Root CA X3 and Ingenico POS

Help
1

Premise: I'm not an HTTPS expert, even if something seems obvious to you, tell me anyway :slight_smile:

My domain is: v5.rt.iride.cards
I ran this command: N/A
It produced this output: N/A
My web server is (include version): Apache 2.4.6-97
The operating system my web server runs on is (include version): CentOS 7.9.2009
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine (yes or no, or I don't know): YES
I'm using a control panel to manage my site: NO
The version of my client is: N/A

Hi everyone.

I'm a little worried about the deadlines of the DST Root CA X3 because we have some POS units that use HTTPS to connect to a secure website with an LE certificate.

Let me explain:

  • The website uses the certificate "DST Root CA X3" -> "R3" -> "v5.rt.iride.cards" which expires on November 21, 2021
  • The clients (Ingenico POS) send and receive inventory data to / from "v5.rt.iride.cards"
  • Currently we have on the POS a file containing (only) the certificate for DST Root CA X3 in the form ----- BEGIN CERTIFICATE ----- etc... and everything works fine

What have I done:

  1. During the tests we tried to upload the ISRG Root X1 certificate in the same form to the POS, but the connection is refused. Panic.
  2. We also tried to upload other different LE certificates (Let's Encrypt R3, Let's Encrypt R3 CrossSigned by IdentiTrust) to the POS with no luck. Double panic.
  3. So I reloaded the DST Root CA X3 file on the POS and the connection works again (but the panic level does not decrease)

Now I'm VERY worried and don't know how to proceed.
To make matters worse, there are only a few days left until the DST Root CA X3 deadline...

Can anyone help me, please?
Fulvio from Northern Italy

1 Like
2

Can you try to remove DST Root CA X3 and add ISRG Root X1 ?

There could be bugs in the stack when DST Root CA X3 is simply present (and shouldn't be used, but breaks connectivity).

3 Likes
3

I can only upload one certificate to the POS, so uploading ISRG Root X1 overwrites the file containing the old DST Root CA X3 -> there is only one certificate on the POS.

1 Like
4

The best i can advise is to contact iride.cards

$ openssl s_client -connect v5.rt.iride.cards: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 = v5.rt.iride.cards
verify return:1
---
Certificate chain
 0 s:CN = v5.rt.iride.cards
   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

and ask them to switch to a shorter chain that ends in ISRG Root X1 without DST Root CA X3.

It's a non default certbot option.

3 Likes
5

Thank you, but WE are iride.cards :slight_smile:

We are currently using https://github.com/srvco/getssl to renew certificates.

Can you please guide me on how to "shorten" the chain, or at least help me understand what that means?

1 Like
6

Maybe I found something useful ...

This screenshot is taken from the getssl website:

2021-09-23 181913
2021-09-23 1819131093×355 40 KB

What do you think?

3 Likes
7

The Let's Encrypt ACME server offers an alternative chain which ACME clients can use. Perhaps getssl supports this feature.

Ah, exactly the option @fmondini pastes above.

3 Likes
8

Yoohoo !!! :slight_smile:

2 Likes
9

OMG =))))) we have the right person to fix this then :wink:

ps. i feel so silly now.

2 Likes
10

this is on the right track, the current default chain is:

  • Default chain: End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3

The chain you want is:

  • Alternate chain: End-entity certificate ← R3 ← ISRG Root X1

And then your terminals should only need "ISRG Root X1"

You should be able to change the full chain on your server yourself, i.e. your entity certificate is the same, it's just a different set of CA certs that are added to make a full chain. Sometimes it split into a separate chain.crt.

PREFERRED_CHAIN is the right option. But some clients were buggy, because "ISRG ROOT X1" is part of both long and short chains. Most clients had to be fixed for this i.e. --preferred-chain: only match root name by aarongable · Pull Request #8596 · certbot/certbot · GitHub

Hopefully the getssl implementation supports --preffered-chain "ISRG ROOT X1" correctly and issues a short chain certs to you.

3 Likes
11

@fmondini if / when you switch to short chain, I expect that:

 openssl s_client -connect v5.rt.iride.cards:443

Does not list anything containing "DST Root CA X3" as in the chain should end on self-signed "ISRG Root X1"

1 Like
12

As far a I can see from the thread the issue is not the server (it's serving a valid chain) but it's your clients who apparently don't know about ISRG Root X1?

You mentioned "uploading a certificate" to the POS:

  • What exactly are you uploading and why?
  • Are you trying to update the trust store (list of root certificates trusted for https by the OS) for the POS or does the POS have it's own client certificate?
  • Are you following some sort of technical manual we could see?
  • What do Ingenico say?
2 Likes
13

Depending on the version of openssl (and the webserver's use of SNI), we might have to use:
openssl s_client -connect v5.rt.iride.cards:443 -servername v5.rt.iride.cards

[to see that particular cert chain]

1 Like
14

Yes.

When we switched from HTTP to HTTPS I had to write a new set of functions in the POS firmware. After days of trying (and blood, and swearing) I ended up with this solution

SSL_ProfileSetProtocol(hSslProf, TLSv1_1);
SSL_ProfileSetCipher(hSslProf, SSL_RSA | SSL_DES | SSL_3DES | SSL_RC4 | SSL_RC2 | SSL_AES | SSL_MD5 | SSL_SHA1 | SSL_SHA256 | SSL_SHA384, SSL_HIGH | SSL_NOT_EXP);

if (FS_exist(CRT_HostCertCAFile))
	SSL_ProfileAddCertificateCA(hSslProf, CRT_HostCertCAFile);

The "CRT_HostCertCAFile" is the DST Root CA X3 text file in this format:

-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
etc, etc, etc...

...and, since it worked... no one has had the courage to change it anymore :slight_smile:

The POS uses the certificate I uploaded to it.
The operation is initiated manually, something like:

SSL_New (& hSSL, hProfile);
SSL_Connect (hSSL, Config.Ftp.OnlServer, Config.Ftp.OnlPort, Config.Ftp.OnlTimeout);
SSL_Write (hSSL, data2send, strlen (data2send), Config.Ftp.OnlTimeout);
_ssl_read_chunks (hSSL, HttpHeader);
_ssl_read_chunks (hSSL, HttpBody);
...etc...

Yes, years ago Ingenico provided us with all the material and documentation relating to the compiler and the SDK, but unfortunately I signed a non-disclosure agreement that prohibits me from making it public.

Same thing always: if you want support you have to pay, and after years and years of paying, I'm starting to get tired.

This afternoon I'll try to change the certificate on the server (as suggested by xnox) and upload the ISRG Root X1 to the POS, and let's see what happens.

I'll keep a fire extinguisher nearby: you never know ... :slight_smile:

4 Likes
15

Ok, so it sounds like you have one trusts store certificate you are trying to update. Have you tried a chain with both ISRG Root X1 (cross signed by DST Root CA X3) and DST Root CA X3

A pem file can include multiple entries. I'm a but pushed for time just now to explain more but maybe someone else could give the required example.

1 Like
16

it looks like they handcrafted that function.. not sure it support multiple certs in that list at all. (ingenico likely would, but this patch not sure, probablely not

1 Like
17

An alternative is to try a cert from ZeroSSL or BuyPass Go, and see if your POS can trust that (they would need to already have a relevant CA root in their trust store).

2 Likes
18

Okay, it looks like I got something. Let's recap:

The SSL libraries in the Ingenico SDK seem to accept more than one certificate in a single file, so I manually chained the two "DST-Root-CA-X3" and "ISRG-Root-X1" into a single file uploaded to the POS.

-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
[...]
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
[...]
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----

Then I tried doing a couple of things on a test website:

  • [Website with older certificates]
    The connection is OK
  • Updated the server with the new certificates obtained with getssl and the parameter PREFERRED_CHAIN="ISRG Root X1" in the configuration file
  • [Website with new certificates]
    The connection is OK

So, in short, IT WORKS !!!

I want to thank everyone who helped me out of this mess. Now the next thing I'm going to do is donate to Let's Encrypt for the wonderful work you do.

Again, thanks everyone.

7 Likes
19

Glad you got it working! While I understand not wanting to touch it any more :slight_smile:, you probably don't need DST Root CA X3 at all anymore, anywhere. Just have ISRG Root X1 loaded into your device, and use the ISRG Root X1 preferred chain, and you should be all set.

[I'm not yet convinced that Let's Encrypt using the weird-chain-for-broken-Android-compatibility as the default, rather then the normal-chain-for-everything-else, was the right call, though I understand why they made the decision they did. But *everything* that's like a "web API" type server (rather than serving "normal" web pages to the general public) should be configured to use the ISRG Root X1 "alternate" chain, and I don't know if the message has gotten out enough to those server administrators. It may be that there was no real right option to pick for the default.]

4 Likes
20

I think you're right, but before we celebrate I want to wait until October 1st, hoping I haven't blocked dozens of supermarkets again. :slight_smile:

3 Likes