|
| 1 | +<?xml version="1.0" encoding="UTF-8"?> |
| 2 | +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" |
| 3 | +"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> |
| 4 | +<section id="security-credential-troubleshooting"> |
| 5 | + <title>Credential Troubleshooting</title> |
| 6 | + |
| 7 | + <section id="security-credential-errors"> |
| 8 | + <title>Credential Errors</title> |
| 9 | + |
| 10 | + <para>The following are some common problems that may cause clients or |
| 11 | + servers to report that credentials are invalid:</para> |
| 12 | + |
| 13 | + <table frame="all" id="credential-errors-table"> |
| 14 | + <title>Credential Errors</title> |
| 15 | + |
| 16 | + <tgroup align="left" cols="3" colsep="1" rowsep="1"> |
| 17 | + <colspec colname="c1" /> |
| 18 | + |
| 19 | + <colspec colname="c2" /> |
| 20 | + |
| 21 | + <colspec colname="c3" /> |
| 22 | + |
| 23 | + <thead> |
| 24 | + <row> |
| 25 | + <entry>Error Code</entry> |
| 26 | + |
| 27 | + <entry>Definition</entry> |
| 28 | + |
| 29 | + <entry>Possible Solutions</entry> |
| 30 | + </row> |
| 31 | + </thead> |
| 32 | + |
| 33 | + <tbody> |
| 34 | + <row> |
| 35 | + <entry><code>Your proxy credential may have expired</code></entry> |
| 36 | + |
| 37 | + <entry>Your proxy credential may have expired.</entry> |
| 38 | + |
| 39 | + <entry>Use <olink targetdoc="gsicPI" |
| 40 | + targetptr="grid-proxy-info">grid-proxy-info</olink> to check |
| 41 | + whether the proxy credential has actually expired. If it has, |
| 42 | + generate a new proxy with <olink targetdoc="gsicPI" |
| 43 | + targetptr="grid-proxy-init">grid-proxy-init</olink>.</entry> |
| 44 | + </row> |
| 45 | + |
| 46 | + <row> |
| 47 | + <entry><code>The system clock on either the local or remote system |
| 48 | + is wrong.</code></entry> |
| 49 | + |
| 50 | + <entry>This may cause the server or client to conclude that a |
| 51 | + credential has expired.</entry> |
| 52 | + |
| 53 | + <entry>Check the system clocks on the local and remote |
| 54 | + system.</entry> |
| 55 | + </row> |
| 56 | + |
| 57 | + <row> |
| 58 | + <entry><code>Your end-user certificate may have |
| 59 | + expired</code></entry> |
| 60 | + |
| 61 | + <entry>Your end-user certificate may have expired</entry> |
| 62 | + |
| 63 | + <entry>Use <olink targetdoc="gsicPI" |
| 64 | + targetptr="grid-cert-info">grid-cert-info</olink> to check your |
| 65 | + certificate's expiration date. If it has expired, follow your CA's |
| 66 | + procedures to get a new one.</entry> |
| 67 | + </row> |
| 68 | + |
| 69 | + <row> |
| 70 | + <entry><code>The permissions may be wrong on your proxy |
| 71 | + file</code></entry> |
| 72 | + |
| 73 | + <entry>If the permissions on your proxy file are too lax (for |
| 74 | + example, if others can read your proxy file), Globus Toolkit |
| 75 | + clients will not use that file to authenticate.</entry> |
| 76 | + |
| 77 | + <entry>You can "fix" this problem by changing the permissions on |
| 78 | + the file or by destroying it (with <olink targetdoc="gsicPI" |
| 79 | + targetptr="grid-proxy-destroy">grid-proxy-destroy</olink>) and |
| 80 | + creating a new one (with <olink targetdoc="gsicPI" |
| 81 | + targetptr="grid-proxy-init">grid-proxy-init</olink>). |
| 82 | + <simpara><emphasis role="strong">Important:</emphasis> However, it |
| 83 | + is still possible that someone else has made a copy of that file |
| 84 | + during the time that the permissions were wrong. In that case, |
| 85 | + they will be able to impersonate you until the proxy file expires |
| 86 | + or your permissions or end-user certificate are revoked, whichever |
| 87 | + happens first.</simpara></entry> |
| 88 | + </row> |
| 89 | + |
| 90 | + <row> |
| 91 | + <entry><code>The permissions may be wrong on your private key |
| 92 | + file</code></entry> |
| 93 | + |
| 94 | + <entry>If the permissions on your end user certificate private key |
| 95 | + file are too lax (for example, if others can read the file), |
| 96 | + grid-proxy-init will refuse to create a proxy certificate.</entry> |
| 97 | + |
| 98 | + <entry>You can "fix" this by changing the permissions on the |
| 99 | + private key file. <simpara><emphasis |
| 100 | + role="strong">Important:</emphasis> However, you will still have a |
| 101 | + much more serious problem: it is possible that someone has made a |
| 102 | + copy of your private key file. Although this file is encrypted, it |
| 103 | + is possible that someone will be able to decrypt the private key, |
| 104 | + at which point they will be able to impersonate you as long as |
| 105 | + your end user certificate is valid. You should contact your CA to |
| 106 | + have your end-user certificate revoked and get a new |
| 107 | + one.</simpara></entry> |
| 108 | + </row> |
| 109 | + |
| 110 | + <row> |
| 111 | + <entry><code>The remote system may not trust your |
| 112 | + CA</code></entry> |
| 113 | + |
| 114 | + <entry>The remote system may not trust your CA</entry> |
| 115 | + |
| 116 | + <entry>Verify that the remote system is configured to trust the CA |
| 117 | + that issued your end-entity certificate. See <olink |
| 118 | + targetdoc="gtadmin"></olink> for details.</entry> |
| 119 | + </row> |
| 120 | + |
| 121 | + <row> |
| 122 | + <entry><code>You may not trust the remote system's |
| 123 | + CA</code></entry> |
| 124 | + |
| 125 | + <entry>You may not trust the remote system's CA</entry> |
| 126 | + |
| 127 | + <entry>Verify that your system is configured to trust the remote |
| 128 | + CA (or that your environment is set up to trust the remote CA). |
| 129 | + See <olink targetdoc="gtadmin"></olink> for details.</entry> |
| 130 | + </row> |
| 131 | + |
| 132 | + <row> |
| 133 | + <entry><code>There may be something wrong with the remote |
| 134 | + service's credentials</code></entry> |
| 135 | + |
| 136 | + <entry>There may be something wrong with the remote service's |
| 137 | + credentials</entry> |
| 138 | + |
| 139 | + <entry>It is sometimes difficult to distinguish between errors |
| 140 | + reported by the remote service regarding your credentials and |
| 141 | + errors reported by the client interface regarding the remote |
| 142 | + service's credentials. If you cannot find anything wrong with your |
| 143 | + credentials, check for the same conditions on the remote system |
| 144 | + (or ask a remote administrator to do so) .</entry> |
| 145 | + </row> |
| 146 | + </tbody> |
| 147 | + </tgroup> |
| 148 | + </table> |
| 149 | + |
| 150 | + <!-- putting in table above |
| 151 | + <section><title>Your proxy credential may have expired</title> |
| 152 | + <para>Use <command>grid-proxy-info</command> to check whether the <glossterm baseform="proxy credentials">proxy credential</glossterm> has actually |
| 153 | +expired. If it has, generate a new proxy with <command>grid-proxy-init</command>. |
| 154 | +</para> |
| 155 | + </section> |
| 156 | + |
| 157 | + <section><title>The system clock on either the local or remote system is wrong</title> |
| 158 | + <para>This may cause the server or client to conclude that a credential has |
| 159 | +expired. |
| 160 | +</para> |
| 161 | + </section> |
| 162 | + |
| 163 | + <section><title>Your <glossterm baseform="user certificate">end-user certificate</glossterm> may have expired</title> |
| 164 | + <para>Use <command>grid-cert-info</command> to check your certificate's expiration |
| 165 | +date. If it has expired, follow your CA's procedures to get a new one.</para> |
| 166 | + </section> |
| 167 | + |
| 168 | + <section><title>The permissions may be wrong on your proxy file</title> |
| 169 | + <para>If the permissions on your proxy file are too lax (for example, if others |
| 170 | +can read your proxy file), Globus Toolkit clients will not use that file |
| 171 | +to authenticate. You can "fix" this problem by changing the permissions |
| 172 | +on the file or by destroying it (with <command>grid-proxy-destroy</command>) and creating a new one (with <command>grid-proxy-init</command>). However, it is still |
| 173 | +possible that someone else has made a copy of that file during the time |
| 174 | +that the permissions were wrong. In that case, they will be able to |
| 175 | +impersonate you until the proxy file expires or your permissions or |
| 176 | +end-user certificate are revoked, whichever happens first.</para> |
| 177 | + </section> |
| 178 | + |
| 179 | + <section><title>The permissions may be wrong on your private key file</title> |
| 180 | + <para>If the permissions on your end user certificate <glossterm>private key</glossterm> file are too lax |
| 181 | +(for example, if others can read the file), <command>grid-proxy-init</command> will |
| 182 | + refuse to create a <glossterm>proxy certificate</glossterm>. You can "fix" this by changing the |
| 183 | +permissions on the private key file; however, you will still have a much |
| 184 | +more serious problem: it's possible that someone has made a copy of |
| 185 | +your private key file. Although this file is encrypted, it is possible |
| 186 | +that someone will be able to decrypt the private key, at which point they |
| 187 | +will be able to impersonate you as long as your end user certificate is valid. |
| 188 | +You should contact your CA to have your end-user certificate revoked and |
| 189 | +get a new one.</para> |
| 190 | + </section> |
| 191 | + |
| 192 | + <section><title>The remote system may not trust your CA</title> |
| 193 | + <para>Verify that the remote system is configured to trust the CA that issued |
| 194 | + your end-entity certificate. See the <olink targetdoc="gtadmin" /> for |
| 195 | +details.</para> |
| 196 | + </section> |
| 197 | + |
| 198 | + <section><title>You may not trust the remote system's CA</title> |
| 199 | + <para>Verify that your system is configured to trust the remote CA (or that |
| 200 | + your environment is set up to trust the remote CA). See the <olink targetdoc="gtadmin" /> for details. |
| 201 | +</para> |
| 202 | + </section> |
| 203 | + |
| 204 | + <section><title>There may be something wrong with the remote service's credentials</title> |
| 205 | + <para>It is sometimes difficult to distinguish between errors reported by the |
| 206 | +remote service regarding your credentials and errors reported by the |
| 207 | +client interface regarding the remote service's credentials. If you |
| 208 | +can't find anything wrong with your credentials, check for the same |
| 209 | +conditions (or ask a remote administrator to do so) on the remote system. |
| 210 | +</para> |
| 211 | + </section> |
| 212 | + --> |
| 213 | + </section> |
| 214 | + |
| 215 | + <section id="security-credential-troubleshooting-tools"> |
| 216 | + <title>Some tools to validate certificate setup</title> |
| 217 | + |
| 218 | + <section> |
| 219 | + <title>grid-cert-diagnostics</title> |
| 220 | + <para> |
| 221 | + The <olink targetdoc="gsicUser" |
| 222 | + targetptr="grid-cert-diagnostics"><command>grid-cert-diagnostics</command></olink> |
| 223 | + program checks prints diagnostics about the user's certificates, and |
| 224 | + host security environment. |
| 225 | + |
| 226 | + <screen><prompt>% </prompt><command>grid-cert-diagnostics</command> <option>-p</option></screen> |
| 227 | + </para> |
| 228 | + </section> |
| 229 | + <section> |
| 230 | + <title>Check that the user certificate is valid</title> |
| 231 | + |
| 232 | + <screen>openssl verify -CApath /etc/grid-security/certificates |
| 233 | + -purpose sslclient ~/.globus/usercert.pem</screen> |
| 234 | + </section> |
| 235 | + |
| 236 | + <section> |
| 237 | + <title>Connect to the server using s_client</title> |
| 238 | + |
| 239 | + <screen>openssl s_client -ssl3 -cert ~/.globus/usercert.pem -key |
| 240 | + ~/.globus/userkey.pem -CApath /etc/grid-security/certificates |
| 241 | + -connect <replaceable><host:port></replaceable></screen> |
| 242 | + |
| 243 | + <para>Here <replaceable><host:port></replaceable> denotes the |
| 244 | + server and port you connect to.</para> |
| 245 | + |
| 246 | + <para>If it prints an error and puts you back at the command prompt, |
| 247 | + then it typically means that the <emphasis>server</emphasis> has closed |
| 248 | + the connection, i.e. that the server was not happy with the client's |
| 249 | + certificate and verification. Check the SSL log on the server.</para> |
| 250 | + |
| 251 | + <para>If the command "hangs" then it has actually opened a telnet style |
| 252 | + (but secure) socket, and you can "talk" to the server.</para> |
| 253 | + |
| 254 | + <para>You should be able to scroll up and see the subject names of the |
| 255 | + server's verification chain:</para> |
| 256 | + |
| 257 | + <screen> |
| 258 | +depth=2 /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1 |
| 259 | +verify return:1 |
| 260 | +depth=1 /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1 |
| 261 | +verify return:1 |
| 262 | +depth=0 /DC=org/DC=doegrids/OU=Services/CN=wiggum.mcs.anl.gov |
| 263 | +verify return:1 |
| 264 | + </screen> |
| 265 | + |
| 266 | + <para>In this case, there were no errors. Errors would give you an extra |
| 267 | + line next to the subject name of the certificate that caused the |
| 268 | + error.</para> |
| 269 | + </section> |
| 270 | + |
| 271 | + <section> |
| 272 | + <title>Check that the server certificate is valid</title> |
| 273 | + |
| 274 | + <para>Requires root login on server:</para> |
| 275 | + |
| 276 | + <screen> |
| 277 | + openssl verify -CApath /etc/grid-security/certificates -purpose sslserver |
| 278 | + /etc/grid-security/hostcert.pem</screen> |
| 279 | + </section> |
| 280 | + </section> |
| 281 | +</section> |
0 commit comments