Nuno Miguel Neves wrote:
I already saw the example for trying to authenticate users using their certificates.
However, instead of using the common name, I would like to use the role of the certificate : CA Operators can access some things, RA Operators some other, Users can not, etc...
How is that done? Can the Role be joined to the DN? How?
Thanks,
General server access control can be managed by PIRMA described briefly below. I've only seen the kind of application access control you are suggesting identified and managed within the application via logon ID / passcode. I don't think OpenSSL provides a convenient facility to share the certificate with the application. Even if it did, it may be desirable to provide a logon ID / passcode for CA / RA application access (or at least pass the logon ID from the DN and require a passcode for access).
Users should not have direct access, but should have a certificate request staging location shared with the RA.
A short "How To" for Private Isolated Root Mutual Authentication (PIRMA)
Create a private CA hierarchy specifically for this purpose. A root and a single subordinate is reasonable for a start. From the server, remove all certificates from the cache. Create a server certificate request and have the certificate issued by the private subordinate CA. Install the complete chain up through the root into the server.
Issue client SSL certificates to ONLY those authorized to access the server.
Set the options for server SSL operation for the following: mutual authentication, session fail on authentication fail. Restrict access to the server except via SSL.
How it works:
When a client attempts to access the server, the server requires that the client submit their certificate (mutual authentication option). When the server attempts to authenticate the client certificate, it will only be able to use the single root certificate from the private hierarchy. If the client can not produce a certificate or if their certificate was issued by a different CA, the server will not be able to authenticate the user certificate. the server will then terminate the session (session fail on authentication fail).
This method of certificate based access control using OpenSSL has been in operation for years in some financial institutions.
Care must be taken to issue certificates only to authorized users. CRLs need to be maintained to restrict use of terminated employees or to limit use through certificate suspension. Analysis should be performed on certificate validity to meet business needs (e.g., contract terms).
Let me know if there are any questions.
Bill
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Openca-Users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-users
