Intermediate cert monitoring
list Eli
Is there any one monitor intermediate cert with xymon? We had issue on intermidate cert but xymon show green because only check the primary cert. Thanks, Elias
list Mark Felder
What was the exact problem with the intermediate certificate? What should be monitored? Maybe we can come up with a way to add additional monitoring parameters to Xymon's SSL monitoring if we know exactly what should be monitored. My first guess is expiration, but I'm not sure if you can sign a cert if it expires after your intermediate is due to expire. The only other thought is if the chain was incomplete...
list Eli
The issue was missing or not installed. As you know newer browsers doesn't have problem but the older one show cert error when the intermediate cert missing. We have bunch of cert so some time engineers forget to install the intermediate cert and caused issue.
▸
Mark Felder <user-db141d317836@xymon.invalid> wrote:
What was the exact problem with the intermediate certificate? What should be monitored? Maybe we can come up with a way to add additional monitoring parameters to Xymon's SSL monitoring if we know exactly what should be monitored. My first guess is expiration, but I'm not sure if you can sign a cert if it expires after your intermediate is due to expire. The only other thought is if the chain was incomplete...
list Eli
I read someone used script on this forum on the past but the answer not include the script anymore. I am really appreciate if some one give me some idea. Thanks! Eli via Xymon <xymon at xymon.com> wrote:
list Ralph Mitchell
Having the Xymon server validate the intermediate certificates won't help if they're missing off the server that owns the certificate. The Xymon server would have the certs installed and always get a match. Where are the intermediate certs missing? Does the web server even start properly if it can't validate its own cert? Ralph Mitchell On Thu, Feb 26, 2015 at 1:51 PM, Eli via Xymon <xymon at xymon.com> wrote:
---------- Forwarded message ----------
▸
From: Eli <user-eeb3a3c6c848@xymon.invalid>
To: Mark Felder <user-db141d317836@xymon.invalid>
Cc: xymon at xymon.com
Date: Thu, 26 Feb 2015 11:50:43 -0700
Subject: Re: [Xymon] Intermediate cert monitoring
The issue was missing or not installed. As you know newer browsers doesn't
have problem but the older one show cert error when the intermediate cert
missing. We have bunch of cert so some time engineers forget to install the
intermediate cert and caused issue.
Mark Felder <user-db141d317836@xymon.invalid> wrote:
What was the exact problem with the intermediate certificate? What
should be monitored? Maybe we can come up with a way to add additional
monitoring parameters to Xymon's SSL monitoring if we know exactly what
should be monitored.
My first guess is expiration, but I'm not sure if you can sign a cert if
it expires after your intermediate is due to expire. The only other
thought is if the chain was incomplete...
list Jeremy Laidman
I'm no expert but I think this has to do with a "certificate chain". In theory, the TLS server only needs to give it's own certificate to the TLS client, or it can optionally send other (intermediate) certificates in the chain, to save the client having to go find them. In practice, the client isn't able to locate the intermediate certificates and so the server generally provides all certificates in the chain as a "certificate bundle". Configuring a web server with only the server's land certificate works just fine if there are no intermediate certificates, such as when the server certificate was issued by a root CA because the client already has the for CA in its trusted certificate store.. But if it was issued by an intermediate CA then the intermediate certificate will not be in the store. The web server should be configured with all certificates in the chain, but sometimes it's not. In such cases it may be possible for libssl (and hence Xymon) to obtain the intermediate certificates and validate them, but not a browser. Actually, I suspect that libssl doesn't validate a trust chain anyway, because unlike a browser, libssl probably has no certificate store. So libssl only checks the reasonableness of a certificate and it's expiry date. J
▸
On 28/02/2015 2:24 PM, "Ralph Mitchell" <user-00a5e44c48c0@xymon.invalid> wrote:Having the Xymon server validate the intermediate certificates won't help if they're missing off the server that owns the certificate. The
Xymon server would have the certs installed and always get a match.
Where are the intermediate certs missing? Does the web server even start properly if it can't validate its own cert? Ralph Mitchell On Thu, Feb 26, 2015 at 1:51 PM, Eli via Xymon <xymon at xymon.com> wrote:---------- Forwarded message ---------- From: Eli <user-eeb3a3c6c848@xymon.invalid> To: Mark Felder <user-db141d317836@xymon.invalid> Cc: xymon at xymon.com Date: Thu, 26 Feb 2015 11:50:43 -0700 Subject: Re: [Xymon] Intermediate cert monitoring The issue was missing or not installed. As you know newer browsers doesn't have problem but the older one show cert error when the intermediate cert missing. We have bunch of cert so some time engineers forget to install the intermediate cert and caused issue. Mark Felder <user-db141d317836@xymon.invalid> wrote: What was the exact problem with the intermediate certificate? What should be monitored? Maybe we can come up with a way to add additional monitoring parameters to Xymon's SSL monitoring if we know exactly what should be monitored. My first guess is expiration, but I'm not sure if you can sign a cert if it expires after your intermediate is due to expire. The only other thought is if the chain was incomplete...
list Jeremy Laidman
Yep. From the openssl s_client man page: " The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors. As a result it will accept any certificate chain (trusted or not) sent by the peer. None test applications should not do this as it makes them vulnerable to a MITM attack. This behaviour can be changed by with the -verify_return_error option: any verify errors are then returned aborting the handshake." Xymonnet probably operates in the same mode. It has to do so if it has no trusted certificate store. J
▸
On 28/02/2015 10:37 PM, "Jeremy Laidman" <user-71895fb2e44c@xymon.invalid> wrote:
I'm no expert but I think this has to do with a "certificate chain". In theory, the TLS server only needs to give it's own certificate to the TLS client, or it can optionally send other (intermediate) certificates in the chain, to save the client having to go find them. In practice, the client isn't able to locate the intermediate certificates and so the server generally provides all certificates in the chain as a "certificate bundle". Configuring a web server with only the server's land certificate works just fine if there are no intermediate certificates, such as when the server certificate was issued by a root CA because the client already has the for CA in its trusted certificate store.. But if it was issued by an intermediate CA then the intermediate certificate will not be in the store. The web server should be configured with all certificates in the chain, but sometimes it's not. In such cases it may be possible for libssl (and hence Xymon) to obtain the intermediate certificates and validate them, but not a browser. Actually, I suspect that libssl doesn't validate a trust chain anyway, because unlike a browser, libssl probably has no certificate store. So libssl only checks the reasonableness of a certificate and it's expiry date. J On 28/02/2015 2:24 PM, "Ralph Mitchell" <user-00a5e44c48c0@xymon.invalid> wrote:Having the Xymon server validate the intermediate certificates won't help if they're missing off the server that owns the certificate. TheXymon server would have the certs installed and always get a match.Where are the intermediate certs missing? Does the web server even start properly if it can't validate its own cert? Ralph Mitchell On Thu, Feb 26, 2015 at 1:51 PM, Eli via Xymon <xymon at xymon.com> wrote:---------- Forwarded message ---------- From: Eli <user-eeb3a3c6c848@xymon.invalid> To: Mark Felder <user-db141d317836@xymon.invalid> Cc: xymon at xymon.com Date: Thu, 26 Feb 2015 11:50:43 -0700 Subject: Re: [Xymon] Intermediate cert monitoring The issue was missing or not installed. As you know newer browsers doesn't have problem but the older one show cert error when the intermediate cert missing. We have bunch of cert so some time engineers forget to install the intermediate cert and caused issue. Mark Felder <user-db141d317836@xymon.invalid> wrote: What was the exact problem with the intermediate certificate? What should be monitored? Maybe we can come up with a way to add additional monitoring parameters to Xymon's SSL monitoring if we know exactly what should be monitored. My first guess is expiration, but I'm not sure if you can sign a cert if it expires after your intermediate is due to expire. The only other thought is if the chain was incomplete...
list Ralph Mitchell
Drifting off-topic just a little here - the client should be able to
validate at least the top-level CA cert via a 3rd-party source. I.e. NOT
solely from the cert chain handed out by the server. In RHEL 5, 6 & 7 that
source is the CA cert bundle under /etc/pki/tls/certs. If you can validate
the chain all the way back to one of those certs, you should be able to
trust the server.
At work I have a couple of RPMs that drop our internal CA certs and all the
current DoD certs into /etc/pki/tls/certs, then rebuild the hash links.
I'm not adding to the original ca-bundle. That allows me to do this:
curl --capath /etc/pki/tls/certs .......
https://internal.server.mine/xxx
and get a validated connection. Drifting back on-topic again, it isn't
hard to fake Xymon's http report from a shell script using a command-line
similar to the above. I'm doing it in a couple of cases where Xymon
doesn't correctly handle going out via a proxy. Curl will tell you if it
validates the cert chain, but ONLY for the server running the script. I
don't think there's any way to tell if some client elsewhere has the proper
intermediate certs installed, other than by running the script there too.
Ralph Mitchell
On Sat, Feb 28, 2015 at 6:43 AM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
▸
wrote:
Yep. From the openssl s_client man page: " The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors. As a result it will accept any certificate chain (trusted or not) sent by the peer. None test applications should not do this as it makes them vulnerable to a MITM attack. This behaviour can be changed by with the -verify_return_error option: any verify errors are then returned aborting the handshake." Xymonnet probably operates in the same mode. It has to do so if it has no trusted certificate store. J On 28/02/2015 10:37 PM, "Jeremy Laidman" <user-71895fb2e44c@xymon.invalid> wrote:I'm no expert but I think this has to do with a "certificate chain". In theory, the TLS server only needs to give it's own certificate to the TLS client, or it can optionally send other (intermediate) certificates in the chain, to save the client having to go find them. In practice, the client isn't able to locate the intermediate certificates and so the server generally provides all certificates in the chain as a "certificate bundle". Configuring a web server with only the server's land certificate works just fine if there are no intermediate certificates, such as when the server certificate was issued by a root CA because the client already has the for CA in its trusted certificate store.. But if it was issued by an intermediate CA then the intermediate certificate will not be in the store. The web server should be configured with all certificates in the chain, but sometimes it's not. In such cases it may be possible for libssl (and hence Xymon) to obtain the intermediate certificates and validate them, but not a browser. Actually, I suspect that libssl doesn't validate a trust chain anyway, because unlike a browser, libssl probably has no certificate store. So libssl only checks the reasonableness of a certificate and it's expiry date. J On 28/02/2015 2:24 PM, "Ralph Mitchell" <user-00a5e44c48c0@xymon.invalid> wrote:Having the Xymon server validate the intermediate certificates won't help if they're missing off the server that owns the certificate. TheXymon server would have the certs installed and always get a match.Where are the intermediate certs missing? Does the web server even start properly if it can't validate its own cert? Ralph Mitchell On Thu, Feb 26, 2015 at 1:51 PM, Eli via Xymon <xymon at xymon.com> wrote:---------- Forwarded message ---------- From: Eli <user-eeb3a3c6c848@xymon.invalid> To: Mark Felder <user-db141d317836@xymon.invalid> Cc: xymon at xymon.com Date: Thu, 26 Feb 2015 11:50:43 -0700 Subject: Re: [Xymon] Intermediate cert monitoring The issue was missing or not installed. As you know newer browsers doesn't have problem but the older one show cert error when the intermediate cert missing. We have bunch of cert so some time engineers forget to install the intermediate cert and caused issue. Mark Felder <user-db141d317836@xymon.invalid> wrote: What was the exact problem with the intermediate certificate? What should be monitored? Maybe we can come up with a way to add additional monitoring parameters to Xymon's SSL monitoring if we know exactly what should be monitored. My first guess is expiration, but I'm not sure if you can sign a cert if it expires after your intermediate is due to expire. The only other thought is if the chain was incomplete...