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 Antwort
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
beantwortet vor einem Jahr

Du bist nicht angemeldet. Anmelden um eine Antwort zu veröffentlichen.

Eine gute Antwort beantwortet die Frage klar, gibt konstruktives Feedback und fördert die berufliche Weiterentwicklung des Fragenstellers.

Richtlinien für die Beantwortung von Fragen