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개 답변
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
답변함 일 년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠