Valery Smyslov writes: > > I think examples of where DN would not be sufficient (and its in the -25 > > text) would be expired certs from the correct CA, or certs from > > a misconfigured registrar with CA - where the operator unintentionally > > re-created a CA with the same DN, instead of going to the correct CA. > > Expired certs can be detected locally, I don't believe this is a problem > (I assume your clock skew is not too large). In case your TA was replaced > by the newer cert with the same DN as result of rollover, you'll > have the Authority Key Identifier from the last cert in the path, > so you'll be able to determine which particular TA with the same DN > your peer intended to use...
All certificate validation issues are something that can really only be debugged locally. In one of the implementations I was aware of there were about half a dozen different error codes returned during the validation problem each listing all errors it hit during the validation, and there is no way of knowing which of them is the actual final cause of the validation failure. I mean you could get LDAP_UNREACHABLE, EXPIRED_CERT, SELF_SIGNED_CERT during the same validation check. This might have been caused because you hit expired intermediate certificate, and there happend to be temporary failure to refetch that intermediate certificate from the LDAP server, and because of thise LDAP failure you used another cross signed certificate ending to the self signed trust anchor which you do not trust. So you get all those tree errors, and the real issue was the LDAP_UNREACHABLE. On the other hand it might have also been that the problem was the intermidiate certificate was expired, and there was no new certificate issued for it because of operation problems, and the LDAP_UNREACHABLE came because we cannot connect to the ldap server specified in that cross signed trust anchor, i.e. the correct problem was EXPIRED_CERT etc... Trying to find out what was the real reason why certificate validation failed is very complicated issue, and usually trying to do it by just having certificate chains is not enough. The only somewhat easy way is to look at the logs of the device and hope they are detailed enough to tell you these kind of things... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
