search

matteocorti / check_ssl_cert

A shell script (that can be used as a Nagios/Icinga plugin) to check an SSL/TLS connection.
GNU General Public License v3.0
368 stars 132 forks source link

Support "Authority Information Access" (AIA) #366

Closed code-and-such closed 2 years ago

code-and-such commented 2 years ago

Is your feature request related to a problem? Please describe.

All current browsers supports AIA (the "Authority Information Access" extension). The server only delivers the site cert, and then the AIA information in the cert tells the browser where it can find the issuer. The browser then proceeds to fetch it from there. Since this kind of alarm very often is about figuring out whether a browser would choke, then I find it reasonable that it support this extension.

A complicating factor is that openssl s_client, which it seems that you depend on do not support this out of box. To do this kind of check, several invocations, or even tools (like curl) would need to be involved. There are blogposts out there how it can be done, and those would be possible to turn into scripts. It would be ideal if openssl themselves included this, of course. I did the lazy thing and placed my ticket here - but it's not unlikely that there is a ticket in their tracker already.

Describe the solution you'd like

A flag to enable this feature. I'm not sure it should be enabled by default - many older clients (older java versions, curl, wget, openssl s_client) do not support it out of box.

Describe alternatives you've considered

Script it myself. But going from a maintained solution, like this one, to a home brewed one, is not overly appealing.

I do not feel I have the time right now to generate a PR - and it's not unlikely that it would ugly up the code to an unacceptable degree.

matteocorti commented 2 years ago

Maybe I understood you wrongly but the plugin is already getting the OCSP URI and the issuer URI from the cert.

Do you have an example of a case when is not working?

lukastribus commented 2 years ago

AIA is not for revocation checking, but to allow the browser to download intermediate certificates somewhere else.

It doesn't make a whole lot of sense to me, especially in a tool for to verify correct SSL configuration, because the correct SSL configuration is to have all needed intermediate certificates configured on the server.

AIA basically helps browsers to validate erroneously configured servers anyway, which is something that a monitoring tool should absolutely not do. A monitoring tool should detect any misconfiguration, not try to "work something out anyway".

matteocorti commented 2 years ago

Anyway the is already checking it. And it makes sense as OCSP has to checked. The behavior can also be optionally disabled.

lukastribus commented 2 years ago

I'm sorry, I did not understand what you are saying.

Are you saying AIA is already implemented and considered? So a server without incorrect configuration (missing intermediate certificates) will return OK to nagios because of AIA (but fail in clients not implementing AIA)?

matteocorti commented 2 years ago

I'm sorry, I did not understand what you are saying.

Are you saying AIA is already implemented and considered?

So a server without incorrect configuration (missing intermediate certificates) will return OK to nagios because of AIA (but fail in clients not implementing AIA)?

It is already implemented. If not working let me know.

lukastribus commented 2 years ago

I think there is come confusion here.

AIA has nothing to do with OCSP or CRL at all, AIA is not about revocation checking.

If AIA is implemented, which command line argument disables it - I cannot find it.

matteocorti commented 2 years ago

Never said anything about CRL. But of course it has to do with OCSP as it delivers the OCSP URI and the issuer URI.

E.g. for GitHub.com

            Authority Information Access: 
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt
lukastribus commented 2 years ago

Right, AIA provides multiple different informations, OCSP is part of that, I did not know that. However that is not the point.

The point is that the OP is talking about fetching intermediate certificates from remote URIs for miss-configured servers (without intermediate certificates or the wrong ones), through AIA provided URI (the CA issuers URI from your github.com output presumably).

I believe this is not implemented and I believe this should NOT be implemented, because its only hiding server configuration issues, which we can argue can be useful in a browser but imho does not belong in a monitoring tool, because in my monitoring I want to actual detect configuration issues.

matteocorti commented 2 years ago

Ok I see your point. The plugin could check both. I never saw anything but the Issuer and OCSP and the moment I am not using the issuer delivered by AIA (since as you state I should check the chain delivered by the server). I'll take a look.

lukastribus commented 2 years ago

My only intention was to make sure we are talking about the same thing. I'm actually advocating to not implement this.

matteocorti commented 2 years ago

I know. I would just like to check if some browsers are using the information and what could happen.

code-and-such commented 2 years ago

It is as you suspected. Apparently our certs to not use OCSP, but only have the CA Issuers part. Using your example it would be 

            Authority Information Access: 
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt

rather than 

            Authority Information Access: 
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt

Apparently browsers buy that too.

matteocorti commented 2 years ago

The plugin should work. Do you have a URL that I could test?