Closed TomasHubelbauer closed 1 month ago
It's not immediately obvious to me how I would read the certificate off the handle in a generic platform independent way... if you can see an obvious path, let me know. https://curl.se/libcurl/c/curl_easy_getinfo.html
It looks as though one of the available options of CURLINFO
is https://curl.se/libcurl/c/CURLINFO_CERTINFO.html. The documentation page includes an example of how to use it.
I unfortunately have no idea if this is platform independent… If it is not, this might not be worth the effort.
However if it is, for this to work and for cURL to not terminate the connection attempt if the certificate was invalid, you'd have to set CURLOPT_SSL_VERIFYPEER
to false
according to a Stack Overlow question I found: https://stackoverflow.com/a/69749451/2715716
I am not sure about this, but as far as I can tell, the certinfo
structure's members are generic KVPs and the certificate information would presumably be one of the key value pairs:
Each certificate's list has items with textual information in the format "name:content" such as "Subject:Foo", "Issuer:Bar", etc. The items in each list varies depending on the SSL backend and the certificate.
If you think this is worth doing, I would stop here and return the KVPs as-is without attempting to come up with some generic ceertificate model and parsing the dictionary to populate it.
Seeing all this, I have become convinced that certificate info inclusion should be an opt-in feature because turning off certificate validation by default seems like a dangerous choice. I still think this would have utility regardless.
Let me know if setting CURLINFO_CERTINFO
and returning the certificate chain as a part of the http_response
type seems doable and worth doing to you.
Seeing nobody else wanting this, and deeply not wanting to change the structure of http_response
, I'm going to tentatively close unless someone reopens.
Hi, I know this is probably a long shot and not many people would use this, but I figure I'll ask just in case.
Would you consider including the information about the SSL certificate of the URL being hit in the
http_response
type?I imagine a bunch of people are using this very Postgres extension to do liveness/content checks on their websites by combining it with something like
pg_cron
. Usually you'd also like to monitor for SSL certificate expirations in addition to the HTTP status / HTTP response body content checks. If this extension exposed the SSL certificate information, it could be a "one-stop-shop" for very simple and convenient website monitoring with no backend needed.Thanks for considering.