Amazon Alexa Plugin

[Jürgen]

So, nach der Änderung der Laufzeitumgebung sofort wieder alles OK :-)

Es gibt auch schon die 14.x die habe ich aber nicht probiert.

Gruß Jürgen

lambda.jpg

[Jürgen]

Hallo,

mein Zertifikat war zu neu für den BOT, da muss noch ein Force in den Befehl:

certbot renew --force-renewal --pre-hook "service nginx stop" --post-hook "service nginx start"

Gruß Jürgen

[lexxmm]

Meine Lambda Version war so alt, dass noch Nodejs4.3 verwendet wurde.

Die nodejs4.3-Laufzeit wird nicht länger unterstützt. Wir empfehlen, die Funktionen, die nodejs4.3 verwenden, zum nächstmöglichen Zeitpunkt zu einer neueren Laufzeit zu migrieren.

Die 4.3 Unterstützt aber die neue StammCert ISRG Root X1 nicht. Daher war keine Verbindung möglich. Wie von AndreK beschrieben einfach auf NodeJS 12 hochsetzen und alles ist wieder in Butter.


VIELEN DANK!


PS: nginx restart nach CertUpdate funktioniert bei mir mit

certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"

wunderbar :-)

das war es Danke! Hatte ich doch echt übersehen das noch 4.3 in Benutzung war..

[ASSR85]

Hallo zusammen,
hatte heute das gleiche Problem. Lösung bei mir (wie hier auch schon gesagt):
Loging in Amazon Account, NodeJs Version auf 12.x ändern. Läuft wieder wie Lack.

Gruß
Aldaris

aldaris kannst du mal schauen was bei dir unter Ziel der Lambda und auch der Auslöser steht? Bei mir hat es das zerschossen..

Grüße Andreas

[aldaris]

Hallo zusammen,
hatte heute das gleiche Problem. Lösung bei mir (wie hier auch schon gesagt):
Loging in Amazon Account, NodeJs Version auf 12.x ändern. Läuft wieder wie Lack.

Gruß
Aldaris

[ASSR85]

Hallo AndreK

ich habe mal nachgeschaut und habe wohl eine alte Version:
[smarthome@SmartHomeNG ~]$ certbot --version
certbot 0.10.2
Ich versuche das mal die Tage upzudaten (ich hoffe es gibt Youtube-Tutorials 😂)


Grüße Andreas

[mode]

Meine Lambda Version war so alt, dass noch Nodejs4.3 verwendet wurde.

Die nodejs4.3-Laufzeit wird nicht länger unterstützt. Wir empfehlen, die Funktionen, die nodejs4.3 verwenden, zum nächstmöglichen Zeitpunkt zu einer neueren Laufzeit zu migrieren.

Die 4.3 Unterstützt aber die neue StammCert ISRG Root X1 nicht. Daher war keine Verbindung möglich. Wie von AndreK beschrieben einfach auf NodeJS 12 hochsetzen und alles ist wieder in Butter.


VIELEN DANK!


PS: nginx restart nach CertUpdate funktioniert bei mir mit

certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"

wunderbar :-)

[AndreK]

Zum Thema abgelaufene Zertifkate,

ich habe heute meine Zertifikate alle erneuert, leider habe ich vorher nicht getestet ob ich das Problem überhaupt hatte.
Ich konnte auf jeden Fall nicht mehr auf meine Web-Seiten zugreifen. Dort gab es definitiv ein Zertifikatsproblem.

Es kamen zwar Hinweise von Letsencrypt, dass gültige Zertifikate vorliegen - ich habe Option 2 gewählt -> jetzt updaten.

Nach dem Update aller Zertifikate funktioniert alles wie gewohnt, Tesfunktionen aus der Lambda gehen ohne Problem durch.
Bedienung via Alexa geht wie gewohnt

Update der Zertifikate auf Debian Stretch mit Certbot Version 0.28.0 - eigener Raspberry nur für Nginx.

Vielleicht hilft es ja

Viele Grüsse Andre

P.S. : Da fällt mir noch was ein - wenn die Zertifikate automatisch aktualisiert werden oder auch manuell, nicht vergessen den NGINX neu zu starten !!

Jürgen : Dein Zertifikat war ja vom 01.10. wurde der NGINX hinterher neu gestartet ?

[mode]

Jürgen In der Lambda Funktion unter dem Reiter Test einen Test Request zu deinem Endpunkt schicken, dann bekommst du den Fehler direkt angezeigt und kannst ihn zusätzlich im CloudWatch Management einsehen.

Komisch: Ich nutze schon das neue StammCert ISRG Root X1 und scheine trotzdem seit Anfang des Monats ein Problem zu haben...

[AndreK]

Hallo,

die Laufzeit-Einstellungen kann man in der Lambda-Funktion unterhalb des Code-Blocks über den Button "Laufzeiteinstellungen" ändern.
Einfach die NodeJS-Version auf die neueste hochnehmen (Node.js 12.x). Unsere Funktion läuft unter 12.x ohne Probleme weiter.

Gruss Andre

[Jürgen]

Hallo Mode, wo findest Du die Meldung?

In der AWS habe ich unter SmartHomeNGFunction nur die Meldung:

• Die nodejs8.10-Laufzeit wird nicht länger unterstützt. Wir empfehlen, die Funktionen, die nodejs8.10 verwenden, zum nächstmöglichen Zeitpunkt zu einer neueren Laufzeit zu migrieren.

Was auch immer das für die Funktion bedeutet, wurde vor drei Jahren erstellt.
Ein Logfile finde ich da nicht..

Gruß Jürgen

[mode]

Bei mir das gleiche Problem,

Mein Endpunkt

root@server:~# openssl s_client -connect alexa.<my_domain.tld> -servername alexa.<my_domain.tld> -showcerts
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = alexa.<my_domain.tld>
verify return:1
---
Certificate chain
0 s:CN = alexa.<my_domain.tld>
i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=CN = alexa.<my_domain.tld>

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4703 bytes and written 407 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 78E483B6541872268FB636FAC95F36B607B4D2AA4F4D693B83 31CA7A81B4B8AC
Session-ID-ctx:
Master-Key: BD01CFEB30B8B545EF8CDAC9637EF97AB85C1F897F615BC8F4 44D7160EB2CCA2DDE120C5CEE8A6228582F6F771EBB9B9
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
...

Start Time: 1633265999
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
closed

Das Log meines AWS Lambda Instanz sagt folgendes

START RequestId: ef70969e-6566-4b66-b74f-6ec156253724 Version: $LATEST
2021-10-03T12:55:21.877Z ef70969e-6566-4b66-b74f-6ec156253724 requesting {"header":{"namespace":"Alexa.ConnectedHome.Contro l","name":"SetPercentageRequest","payloadVersion": "2","messageId":"64df5cc9-b633-403c-9ce4-fa2c89463403"},"payload":{"accessToken":"Atza|IwEB xxxx ","appliance ":{"applianceId":"licht_arbeitszimmer","additional ApplianceDetails":{"item2":"licht.arbeitszimmer"," item1":"licht.arbeitszimmer.dim_abs"}},"percentage State":{"value":60}}}
2021-10-03T12:55:22.006Z ef70969e-6566-4b66-b74f-6ec156253724 request failed { [Error: certificate has expired] code: 'CERT_HAS_EXPIRED' }
2021-10-03T12:55:22.007Z ef70969e-6566-4b66-b74f-6ec156253724 {"errorMessage":"certificate has expired","errorType":"Error","stackTrace":["Error (native)","TLSSocket.<anonymous> (_tls_wrap.js:1016:38)","emitNone (events.js:67:13)","TLSSocket.emit (events.js:166:7)","TLSSocket._finishInit (_tls_wrap.js:585:8)"]}
END RequestId: ef70969e-6566-4b66-b74f-6ec156253724
REPORT RequestId: ef70969e-6566-4b66-b74f-6ec156253724 Duration: 132.03 ms Billed Duration: 133 ms Memory Size: 512 MB Max Memory Used: 55 MB

Das ganze lief jetzt gut 5 Jahre völlig Problemlos. Seit heute nicht mehr. Jemand eine Idee?

Endpunkt ist ein nginx auf Ubuntu 20.04:

root@tulpe:/var/log/nginx# cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

root@tulpe:/var/log/nginx# nginx -V
nginx version: nginx/1.18.0 (Ubuntu)
built with OpenSSL 1.1.1f 31 Mar 2020
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-KTLRnK/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-compat --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-KTLRnK/nginx-1.18.0/debian/modules/http-auth-pam --add-dynamic-module=/build/nginx-KTLRnK/nginx-1.18.0/debian/modules/http-dav-ext --add-dynamic-module=/build/nginx-KTLRnK/nginx-1.18.0/debian/modules/http-echo --add-dynamic-module=/build/nginx-KTLRnK/nginx-1.18.0/debian/modules/http-upstream-fair --add-dynamic-module=/build/nginx-KTLRnK/nginx-1.18.0/debian/modules/http-subs-filter --add-dynamic-module=/build/nginx-KTLRnK/nginx-1.18.0/debian/modules/http-geoip2

root@tulpe:/var/log/nginx# certbot --version
certbot 0.40.0

[AndreK]

Hallo Jürgen ,

sieht gut aus -

i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

Dann doch mal in den Cloud-watch logs nachsehen

[Jürgen]

Hi,

immer diese DAUs, die alles einfach abtippen :-)
Macht MICH aber auch nicht schlauer :-(

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <my domain>
verify return:1
---
Certificate chain
0 s:CN = <my Domain>
i:C = US, O = Let's Encrypt, CN = R3

-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----


-----END CERTIFICATE-----
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=CN = <my domain>

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5163 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 565AC7A4A208A76F2D5D
Session-ID-ctx:
Master-Key: 9AD1935EA47E0192FE7
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 42 4b 1f 41 e9 fb ce be-b1
0010 - 66 3a 71 ce 72 88 da 7a-09 1
0020 - 54 51 be c4 ce a4 27 5a-6f 06 0
0030 - 6b 64 d9 ab 12 b9 b7 5a-1b e2 6c
0040 - d3 11 b5 95 cb 8b 4f 68-f0 13 5e
0050 - 76 ae e9 93 1d f8 a7 77-a5 77 b
0060 - 7d a2 fc 02 0c 52 52 52-
0070 - 89 0f 52 ed 9e 3c 2
0080 - 32 eb db 69 b0 e0
0090 - 95 4d b1 9b 17 5f 4
00a0 - 2e b5 c9 63 c4 7b 08

Start Time: 1633259697
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
closed

[AndreK]

Jürgen ,

die Adresse für deine Domain konnte nicht aufgelöst werden bzw. es wurde auf dem falschen Port gesucht.

Falls Dein Nginx auf einem anderen Port als 443 lauscht mußt Du bei der ersten URL den Port, getrennt mit Doppelpunkt angeben:

<DEINE_DOMAIN>.<TLD>:PORT