- Check that root of the certificate chain is trusted. First issuer should be the subject and issuer of a certificate in the authorites list (those are "self-signed", i.e. subject = issuer).
I'm not sure this is correct, as you could have a second tier authority, in which case your "root authority" isn't self signed.
It's years since I read the SSL spec, but I wouldn't be surprised if it says that the first cert in the list has to be a root "self-signed" cert.
But it doesn't really matter, if you (as a verifier) provide a list of "trusted" root certs to the SSL module, then it could accept the chain if the first cert is either equal to one of the trusted certs, or issued by one of the trusted certs. As far a I can see, there's no difference from a security point of view.
Perhaps it would be better to pass the certificate or issuer to a callback, which would then give a thumbs up or down on the presented certificate
That's a nice option to have, but I don't think it should be the default behaviour, as it makes it unnecessarily difficult to get the security right.
An SSL client must to examine the certificate anyway, to compare the URL hostname to the certified "Common Name". I can't say if that should be a callback, or some attribute that can be examined after a successful connect. And that's all about server certs. What rules people want to apply to client certificates I don't know, but it might make some sense with an ACL where each entry is a trusted root cert and a specification of a subtree in the x.500 directory..
/ Niels Möller (vässar rödpennan)
Previous text:
2004-01-23 21:06: Subject: Re: SSL part two
I think the authorities and auth_level should be removed from handshake.pike. Having the same variables in handshake.pike and context.pike is confusing and invites bugs.
Good idea, this is done.
- Check that root of the certificate chain is trusted. First issuer should be the subject and issuer of a certificate in the authorites list (those are "self-signed", i.e. subject = issuer).
I'm not sure this is correct, as you could have a second tier authority, in which case your "root authority" isn't self signed. Either way, coding this would just enforce our view of what a valid certificate was based on a very narrow usage scenario. Perhaps it would be better to pass the certificate or issuer to a callback, which would then give a thumbs up or down on the presented certificate (strictly from a "name on the front door sort of way, no validity checks made).
I'm thinking I might be getting in a little too deep, so comments are welcome.
Bill
/ Brevbäraren