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 ?

preguntada hace un año972 visualizaciones
1 Respuesta
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
respondido hace un año

No has iniciado sesión. Iniciar sesión para publicar una respuesta.

Una buena respuesta responde claramente a la pregunta, proporciona comentarios constructivos y fomenta el crecimiento profesional en la persona que hace la pregunta.

Pautas para responder preguntas