The domain is running on a Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-100-generic x86_64) instance.
Then invoking openssl s_client -connect market.saltalafila.online:443 was showing a certificate that was not in the /etc/letsencrypt/live directories with the name: "artaterme.saltalafila.online"
I thus went and combed through the certificates, where yours truly had doubled some up... sudo certbot delete --cert-name #{unnecessary_cert}
Yet now odder things are happening:
$ openssl s_client -connect market.saltalafila.online:443 -cert certname
Can't open certname for reading, No such file or directory
139806406096192:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('certname','r')
139806406096192:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
unable to load client certificate private key file
$ openssl s_client -connect market.saltalafila.online:443 -certform format
s_client: Invalid format "format" for -certform
s_client: Use -help for summary.
One can connect via browser to market.saltalafila.online and the browser reports everything fine. Yet openssl s_client -connect market.saltalafila.online:443 is still pumping out a reference to a cert with the apparent name 'artaterme.saltalafila.online'. No file with that name is found on the server.
There are numerous odd things here. We probably need more information about what you're attempting to do.
I noticed the following oddities:
When using openssl s_client together with -cert, you're attempting to use TLS client authentication. TLS client authentication is rarely used in the web domain and the server market.saltalafila.online is also not requesting any client certificate. So any options relating to client authentication ( -certform, -cert) are not valid for what you're attempting to do.
It appears as if this might actually be OpenSSL v0.9.8. OpenSSL 0.9.8 is from 2005 (last patch released 2015) and does not support any modern, secure TLS version such as TLS v1.2. Your server however is configured to only accept TLS v1.2 and higher (a common choice nowadays). That means that it's impossible to connect with an ancient OpenSSL version to that server. That OpenSSL version also has numerous security issues.
A certificate may contain multiple alternative names (SANs). OpenSSL might only print the Common Name (CN), which is usually just one of the SANs. As long as there is no certificate validation error, all is fine.
There are 6 certificates on this server, with validities of 84, 76, 76, 89, 34 and 51 days.
So the query must be routing to someplace unexpected and hitting a hidden cert.
From the detailed stack trace there are two inflexion points I deemed worthy of intercepting.
From the gem:
/shared/bundle/ruby/2.6.0/gems/telegram-bot-0.15.4/lib/telegram/bot/client.rb:73:in `request'
is calling method
def http_request(uri, body)
client.post(uri, body)
end
and the uri is https://market.saltalafila.online//bot#{bot_id}:#{bot_token}/setWebhook
and the final step where the failure occurs:
if hostname && @ssl_socket.respond_to?(:hostname=)
@ssl_socket.hostname = hostname
end
Rails.logger.info @ssl_socket.hostname
@ssl_socket.connect
This is a common error usually related to the expiry of DST Root CA X3 last year.
Fixing this most likely requires updating your client system trust store (ca-certificates) to include ISRG Root X1. If you're running OpenSSL < 1.1, additional workarounds must be applied.
I am uncertain if I have a solid answer to that. Based on the code above and this is the point in the stack trace where the action stops executing and throws the certificate has expired error, the information logging that domain market.saltalafila.online which, yes, everything looks fine for TLS.
I have yet to uncover how/where this all gets routed to.
I think this thread can be closed, for I have devised a test where another app on an older server is connecting properly to set Telegram webhooks, but this newer version not. It may not be Ruby, but the library that is the culprit. More digging...
For posterity's sake, capturing the arguments of http_request(uri, body) allowed to find a way through the immediate issue and clearly pointing to a problem with the telegram-bot gem.
The uri value is misleading, the body instead is telling how it is connecting to the API: {:url=>"https://market.saltalafila.online/telegram/#some_uniq_code}", :certificate=>nil, :ip_address=>nil, :drop_pending_updates=>false}
If one connects directly via the API webhooks curl command with just the url parameter (no mention of certificates or ip_addresses, the webhook is set. Then a command to the application hits the controller and is logged as any normal action.
This is the http client you're talking about, right?
You don't set a certificate in the client, if you don't have a client authentication certificate. (Which Let's Encrypt ones are, but when used as client authentication certificates -- I haven't seen this on the community yet).