You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a user attempts to talk to CHAPI with an old cert (one that has been replaced in the MA tables) the SSL connection works fine. And probably other calls (Like lookup_slices) work fine. But we fail to provide a user credential or slice credential because the cert on the wire doesn't match the cert in the inside or outside database tables.
We probably should catch this case early on (in MethodContext, perhaps) and raise a standard Exception with a good explanatory message.
Imported from trac ticket #299, created by mbrinn on 05-23-2014 at 09:24, last modified: 05-23-2014 at 17:04
The text was updated successfully, but these errors were encountered:
We've talked about this: rather than trying to preclude using such certs we should allow them. Specifically, don't require in the MA that the cert on the wire matches the DB cert.
Excerpting an email from Tom:
I like the idea of using the certificate passed to get_user_credential instead of trying to match it in the database. In other words, I’m choosing the “we should accept them” option above. I think we should accept valid certificates at the door only on the basis of expiration and CRLs and trust roots. Very standard stuff. Once in, we should honor that cert.
We should check that the user isn't disabled but that should be the case in the guard in MethodContext.
Trac comment by mbrinn (github user: MarshallBrinn) on 05-23-2014 at 10:19
When a user attempts to talk to CHAPI with an old cert (one that has been replaced in the MA tables) the SSL connection works fine. And probably other calls (Like lookup_slices) work fine. But we fail to provide a user credential or slice credential because the cert on the wire doesn't match the cert in the inside or outside database tables.
We probably should catch this case early on (in MethodContext, perhaps) and raise a standard Exception with a good explanatory message.
Imported from trac ticket #299, created by mbrinn on 05-23-2014 at 09:24, last modified: 05-23-2014 at 17:04
The text was updated successfully, but these errors were encountered: