Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
Reference
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Samples
- Glossary
- Performance Studies
Common Runtime
Security
Data Mgt
Information Svcs
Execution Mgt
Table of Contents
This guide contains advanced configuration information for system administrators working with Message/Transport-level Security. It provides references to information on procedures typically performed by system administrators, including installing, configuring, deploying, and testing the installation.
![[Important]](/docbook-images/important.gif) | Important |
|---|---|
This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in the GT 4.1.1 System Administrator's Guide. Read through this guide before continuing! |
The main administration issues for this component deal with configuring credential related settings. There are multiple mechanisms for doing this:
Security Descriptors
- Container Security Descriptor: This is the preferred mechanism.
- Service Security Descriptor
- CoG properties
- Environment variables
- Relying on default behavior. The only default behaviors available concern the proxy file and trusted certificates locations.
More information on these mechanisms can be found in the public interface guide.
The GT4 Message & Transport Level Security component is currently installed as part of the GT4 Java WS Core component. More information on installing this component can be found in the "Building and Installing" section of the Java WS Core Admin Guide.
Configuration of service-side security settings can be achieved in two ways. The preferred way is to provide these settings in a security descriptor, although it is also possible to manipulate security settings via CoG properties.
Information on the syntax of security descriptors can be found in Java WS Security Descriptor Framework .
Information on available CoG security properties can be found Section 3.1, “Trusted Certificates Location”
The GT4 Message & Transport Level Security component is currently deployed as part of the GT4 Java WS Core component.
The GT4 Message & Transport Security tests are intermingled with tests for the GT4 Authorization Framework and thus are also executed when running the authorization tests. Information on how to run the authorization tests can be found in Section 5, “Testing”.
The Java security code currently does not enforce secure permissions and, implicitly, file ownership requirements on any of the security related files, e.g. configuration and credential files. It is thus important that administrators ensure that the relevant files have correct permissions and ownership. Permissions should generally be as restrictive as possible, i.e. private keys should be readable only by the file owner and other files should be writable by owner only, and the files should generally be owned by the globus user (the requirements that the C code enforces are documented in Section 8, “Configuration interface”).
Also refer to Section 5, “Known Problems” for details on any other open issues.
This error occurs when globus-start-container is run without any valid credentials. Either a proxy certificate or service/host certificate needs to be configured for the container to start up
Solutions:
If you are not looking to start up a container that uses GSI Secure Transport, which is used by the container by default, use "globus-start-container -nosec". You will be able to use insecure clients and services. However, this also implies that if you have not configured individual services with credentials, you will not be able to securely access the service.
If you are running a personal container, generate proxy certificate. If proxy certificate is not in default, configure container security descriptor as described Configuring Container Security Descriptor
If you are looking to use host certificates, configure container security descriptor as described Configuring Credentials
This error occurs if the file path to the container certificate and key configured are invalid.
Solutions:
The path to container certificate and key are configured in $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml. This file is loaded as described here. Ensure that the path is correct.
This error occurs if container proxy file configured is invalid.
Solutions:
The path to container proxy certificates are configured in $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml. This file is loaded as described here. Ensure that the path is correct.
This error occurs if the container security descriptor configured is invalid.
Solutions:
The container security descriptor should conform to the Container Security Descriptor Schema
Refer to the "Caused by: " section for details on specific element that is not correct.
This error occurs if the CA certificate for the credentials being used is not installed correctly.
Solutions:
If this issue occurs on the server side, the container is not configured with CA certificates. The container looks for trusted certificates in default location as described Java CoG Toolkit FAQ
On the server side the trused certificates can be configured as described in Trusted Certificates
On the client side, trusted certificates can be configured as described in Configuring Trusted Credentials
The following are some common problems that may cause clients or servers to report that credentials are invalid:
Use grid-proxy-info to check whether the proxy credential has actually expired. If it has, generate a new proxy with grid-proxy-init.
This may cause the server or client to conclude that a credential has expired.
7.2.1.3. Your end-user certificate may have expired
Use grid-cert-info to check your certificate's expiration date. If it has expired, follow your CA's procedures to get a new one.
If the permissions on your proxy file are too lax (for example, if others can read your proxy file), Globus Toolkit clients will not use that file to authenticate. You can "fix" this problem by changing the permissions on the file or by destroying it (with grid-proxy-destroy) and creating a new one (with grid-proxy-init). However, it is still possible that someone else has made a copy of that file during the time that the permissions were wrong. In that case, they will be able to impersonate you until the proxy file expires or your permissions or end-user certificate are revoked, whichever happens first.
If the permissions on your end user certificate private key file are too lax (for example, if others can read the file), grid-proxy-init will refuse to create a proxy certificate. You can "fix" this by changing the permissions on the private key file; however, you will still have a much more serious problem: it's possible that someone has made a copy of your private key file. Although this file is encrypted, it is possible that someone will be able to decrypt the private key, at which point they will be able to impersonate you as long as your end user certificate is valid. You should contact your CA to have your end-user certificate revoked and get a new one.
Verify that the remote system is configured to trust the CA that issued your end-entity certificate. See the GT 4.1.1 System Administrator's Guide for details.
Verify that your system is configured to trust the remote CA (or that your environment is set up to trust the remote CA). See the GT 4.1.1 System Administrator's Guide for details.
It is sometimes difficult to distinguish between errors reported by the remote service regarding your credentials and errors reported by the client interface regarding the remote service's credentials. If you can't find anything wrong with your credentials, check for the same conditions (or ask a remote administrator to do so) on the remote system.
openssl verify -CApath /etc/grid-security/certificates -purpose sslclient ~/.globus/usercert.pem
openssl s_client -ssl3 -cert ~/.globus/usercert.pem -key ~/.globus/userkey.pem -CApath /etc/grid-security/certificates -connect <host:port>
Here <host:port> denotes the server and port you connect to.
If it prints an error and puts you back at the command prompt, then it typically means that the server has closed the connection, i.e. that the server was not happy with the client's certificate and verification. Check the SSL log on the server.
If the command "hangs" then it has actually opened a telnet style (but secure) socket, and you can "talk" to the server.
You should be able to scroll up and see the subject names of the server's verification chain:
depth=2 /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1
verify return:1
depth=1 /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
verify return:1
depth=0 /DC=org/DC=doegrids/OU=Services/CN=wiggum.mcs.anl.gov
verify return:1
In this case there were no errors. Errors would give you an extra line next to the subject name of the certificate that caused the error