Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CHAPI accepts connections from old certs but won't generate credentials #299

Closed
MarshallBrinn opened this issue May 20, 2015 · 3 comments
Closed
Assignees
Milestone

Comments

@MarshallBrinn
Copy link
Contributor

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

@MarshallBrinn MarshallBrinn added this to the 1.12 milestone May 20, 2015
@ahelsing
Copy link
Member

It is in fact only the MA call to get_credentials which checks that the cert you are using is in the inside or outside certs tables.

Getting your slice cred uses whatever the client_cert is on the call. The SA does not look at what cert you are using.

No other SA or MA calls check your cert in any way.

The real fix here might be to use CRLs to check that you aren't using a cert that has since been replaced.

Trac comment by ahelsing on 05-23-2014 at 09:30

@MarshallBrinn
Copy link
Contributor Author

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

@tcmitchell
Copy link
Member

Changed to use the invoking certificate in the user credential.

Trac comment by tmitchel (github user: tcmitchell) on 05-23-2014 at 17:04

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants