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 Answer
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
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions