AWS API gateway SSL handshake error because of the old system time

0

We have a bunch of machines with incorrect system time (currently 2019) and we are doing a cURL to an API gateway endpoint resulting in an empty response. Upon debugging we found that the cURL fails at SSL handshake phase indicating a certificate error.

:FYI:+* Trying 1.2.3.4... :FYI:+* TCP_NODELAY set :FYI:+* Expire in 149969 ms for 3 (transfer 0x2820088) :FYI:+* Expire in 200 ms for 4 (transfer 0x2820088) :FYI:+* Connected to telemetry.abc.def.com (1.2.3.4) port 443 (#0) :FYI:+* ALPN, offering h2 :FYI:+* ALPN, offering http/1.1 :FYI:+* successfully set certificate verify locations: :FYI:+* CAfile: C:\eDrive\23\11\sw\tools\win32\curl\curl-7.64.0-win32-mingw\bin\curl-ca-bundle.crt :FYI:+ CApath: none :FYI:+} [5 bytes data] :FYI:+* TLSv1.3 (OUT), TLS handshake, Client hello (1): :FYI:+} [512 bytes data] :FYI:+* TLSv1.3 (IN), TLS handshake, Server hello (2): :FYI:+{ [104 bytes data] :FYI:+* TLSv1.2 (IN), TLS handshake, Certificate (11): :FYI:+{ [4959 bytes data] :FYI:+* TLSv1.2 (OUT), TLS alert, bad certificate (554): :FYI:+} [2 bytes data] :FYI:+* SSL certificate problem: certificate is not yet valid :FYI:+* Closing connection 0

Is there a way to fix the issue without updating the system time ?

1 Risposta
0

In the TLS handshake process the client system time is used to test the validity of the certificate. When the client and server device date/time are off significantly it can make the certificate appear to be expired. I don't think there is a workaround for this.

Since you are using curl, have you tried the -k or --insecure syntax to ignore SSL certificate warnings?

profile picture
con risposta un anno fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande