Authorization not found. TLS handshake error. Connection reset by peer

The problem:
I’ve recently migrated hardware to a newer server (all software versions match) and I started having some strange influx errors in the log:

Feb 01 15:44:45 REDACTED influxd-systemd-start.sh[2678]: ts=2023-02-01T15:44:45.286157Z lvl=info msg=Unauthorized log_id=0fkNclAl000 error=“authorization not found”
Feb 01 15:44:51 REDACTED influxd-systemd-start.sh[2678]: ts=2023-02-01T15:44:51.063622Z lvl=info msg=“http: TLS handshake error from 127.0.0.1:48304: EOF” log_id=0fkNclAl000 service=http
Feb 01 15:44:54 REDACTED influxd-systemd-start.sh[2678]: ts=2023-02-01T15:44:54.064662Z lvl=info msg=“http: TLS handshake error from 127.0.0.1:48330: EOF” log_id=0fkNclAl000 service=http
Feb 01 15:44:54 REDACTED influxd-systemd-start.sh[2678]: ts=2023-02-01T15:44:54.079118Z lvl=info msg=“http: TLS handshake error from 127.0.0.1:48322: read tcp 127.0.1.1:8086->127.0.0.1:48322: read: connection reset by peer” log_id=0fkNclAl000 service=http
Feb 01 15:44:54 REDACTED influxd-systemd-start.sh[2678]: ts=2023-02-01T15:44:54.080827Z lvl=info msg=“http: TLS handshake error from 127.0.0.1:48342: EOF” log_id=0fkNclAl000 service=http
Feb 01 15:44:55 REDACTED influxd-systemd-start.sh[2678]: ts=2023-02-01T15:44:55.286243Z lvl=info msg=Unauthorized log_id=0fkNclAl000 error=“authorization not found”

Software versions:
I’m using:

  • InfluxDB v2.6.1 (git: 9dcf880fe0) build_date: 2022-12-29T15:53:07Z
  • Grafana Version 9.3.6 (commit: 978237e7cb, branch: HEAD)
  • Telegraf 1.25.1 (git: HEAD@e1a0d74e)
  • Ubuntu 22.04.1 LTS

I’ve enabled SSL in /etc/influxdb/config.toml using self signed certificates:

https-enabled = true
tls-cert = "/etc/ssl/influxdb-selfsigned.crt"
tls-key = "/etc/ssl/influxdb-selfsigned.key"
https-certificate = "/etc/ssl/influxdb-selfsigned.crt"
https-private-key = "/etc/ssl/influxdb-selfsigned.key"

What I’ve tried:

  • I’ve double checked configurations for Telegraf and Grafana data sources and everything looks fine.
  • I have some LAN clients that use the Influx Python libraries to API write information back to the InfluxDB, but none of these are erroring and data is being submitted Ok. The libraries (and the OS’s) are up to date.
  • I’ve also tried regenerating Influx Tokens for everything, whilst double checking that database access is correct.
  • I’ve followed this guide: https://docs.influxdata.com/influxdb/v2/admin/security/enable-tls/
    And everything is as it should be, except file permissions to the certificates are 0777.
  • This is my TLS verification which fails for some reason:
curl -v -k https://localhost:8086/api/v2/ping
*   Trying 127.0.0.1:8086...
* Connected to localhost (127.0.0.1) port 8086 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=GB; ST=Some-State; O=REDACTED; CN=REDACTED
*  start date: Jan 30 15:23:23 2023 GMT
*  expire date: Jan 30 15:23:23 2024 GMT
*  issuer: C=GB; ST=Some-State; O=REDACTED; CN=REDACTED
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x55b54f97dc60)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /api/v2/ping HTTP/2
> Host: localhost:8086
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 401
< content-type: application/json; charset=utf-8
< x-influxdb-build: OSS
< x-influxdb-version: v2.6.1
< x-platform-error-code: unauthorized
< content-length: 55
< date: Wed, 01 Feb 2023 16:04:50 GMT
<
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host localhost left intact
{"code":"unauthorized","message":"unauthorized access"}

Questions:
Why is my TLS verification failing?
And is there anyway I can find out more information, like which client is trying to communicate and is getting ‘not authorized’ in the logs?

Anyone able to help or point me in the right direction of who to ask?

Any help with this at all?

Hello @olliecampbell,
Sorry I missed this. Thank you for asking again. Please @ me in the future. I don’t know the answer to this question but let me ask the team.
I’d also suggest creating an issue on gh.

1 Like

Hi @olliecampbell ,

From the log, it looks like the script that starts InfluxDB (usually located at /usr/lib/influxdb/scripts/influxd-systemd-start.sh) is the source of the error message. The error is from the last part of the script that waits for InfluxDB to fully start so that other systemd units with InfluxDB dependencies start properly.

Couple of ideas:

  1. Do you eventually see the message InfluxDB started in the logs? If so, the TLS handshake errors are due to InfluxDB listening on the port, but not being ready to serve requests yet. If so, you can ignore the TLS handshake error messages.
  2. Check that you see the TLS cert and key found -- using https earlier in the log. If you don’t see that, it’s possible the script isn’t properly detecting your TLS configuration (influxd.conf not in standard location?).

Hi @gwossum @Anaisdg

I certainly did get those messages:

Jun 13 14:54:19 SERVERNAME influxd-systemd-start.sh[32115]: InfluxDB started
Jun 13 15:26:49 SERVERNAME influxd-systemd-start.sh[780]: InfluxDB started

and…

Jun 13 14:54:15 SERVERNAME influxd-systemd-start.sh[32115]: TLS cert and key found – using https
Jun 13 15:26:44 SERVERNAME influxd-systemd-start.sh[780]: TLS cert and key found – using https

I don’t know if this helps but I’ve found that the source of these messages is Grafana (obviously located on the same machine) which is configured for TLS and ignoring the self signed certificate.

@olliecampbell Did updating your Grafana config make the TLS handshake errors stop? I’m surprised the unit shows up as the startup script in the logs instead of influxdb, but systemd can be mysterious.

If you see TLS handshake error messages in between the TLS cert and key found -- https and InfluxDB started in the logs, its probably because InfluxDB is listening but not actually serving the endpoints yet.

Hi @gwossum
Nope, everything is fully up to date on that machine and the errors are still there.

EDIT: Just updated to Grafana v10. Issue still exists.

And again, updated to Grafana v10.0.1 and it’s still an issue.

@gwossum @Anaisdg

Still here with v10.0.3.

Every time a Grafana dashboard is refreshed (either the refresh button, or the dashboard is ‘opened’ by switching to it in a tab that has been left dormant in the background).
The number of these errors seems to relate to the number of visualisations on the Grafana dashboard. All of them identical, except the port number.

@gwossum @Anaisdg

Hey @olliecampbell @Anaisdg,
Any news on the subject? I have the same issue on Proxmox API:

curl -vvv -u "root@pam:test" https://172.16.20.11:8006/api2/json
*   Trying 172.16.20.11:8006...
* Connected to 172.16.20.11 (172.16.20.11) port 8006 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: OU=PVE Cluster Node; O=Proxmox Virtual Environment; CN=tank
*  start date: Aug  7 10:09:45 2023 GMT
*  expire date: Aug  6 10:09:45 2025 GMT
*  subjectAltName: host "172.16.20.11" matched cert's IP address!
*  issuer: CN=Proxmox Virtual Environment; OU=54121152-......-a7245d141c5c; O=PVE Cluster Manager CA
*  SSL certificate verify ok.
* using HTTP/1.x
* Server auth using Basic with user 'root@pam'
> GET /api2/json HTTP/1.1
> Host: 172.16.20.11:8006
> Authorization: Basic cm9.......MDQ=
> User-Agent: curl/7.88.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 401 No ticket
< Cache-Control: max-age=0
< Connection: close
< Date: Wed, 28 Feb 2024 11:42:51 GMT
< Pragma: no-cache
< Server: pve-api-daemon/3.0
< Expires: Wed, 28 Feb 2024 11:42:51 GMT
< 
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):

Where you can notice the HTTP/1.1 401 error.

The same command with the API token returns the exact same output (except the Basic).

Regards