Reputation: 45
I use a server running EZProxy software, which is an Apache-like server that proxies web activity and is commonly used by academic libraries to authenticate off-campus users to library resources. For my institution, EZProxy operates as a pseudo-CAS server for a separate server running DSpace, which is a Java-based document repository software. Users authenticate into DSpace using EZproxy, which passes authentication information in a CAS-like way to the DSpace client.
We had previously encountered a problem with our set up that we discovered had to do with the certificate being encoded with greater than 1024 bits, which we resolved by generating DH parameters and appending them to the cert and intermediaries according to these instructions, which worked great. Now we have a new security certificate. I installed the new certificate, generated new DH parameters using
openssl dhparam 1024
appended the DH parameters to the newly installed certificate just as I had done before, and restarted the EZProxy server. However, when I activate the new certificate and DH params, I'm getting the same error in DSpace:
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate
DH keypair
I think I need to understand more clearly what happens when the keypair is generated during the handshake. Is it possible that something is cached on the DSpace / Java server? When we troubleshooted this before, our DSpace admin reset our CAS authentication settings configuration several times, which we are going to try during off hours but I'm just trying to conceptually understand why that would make a difference.
From looking at the documentation about Diffie-Hellman it looks like when this type of handshake is set up, a shared secret is passed between servers, however when we got this to work the first time, we never installed anything on the DSpace side - we just reset the authentication configuration a few times.
Is it possible the DSpace server is cacheing information from the DH parameters upon the initial setup of the EZProxy server as a CAS authentication source? Am I doing something wrong in generating the DH parameters and appending them to my certificate - is there another step that would need to be done to wipe out the old DH parameter appended to the old cert? Why can't I reuse the old DH parameters with the new certificate? I tried that and the same error occurred - could not generate DH keypair. However, if I switch the certificate back to the old certificate - including the old DH keypair appended to the x509 certificate and intermediaries - authentication works again.
Thanks for any troubleshooting advice!
Upvotes: 1
Views: 1040
Reputation: 45
This is resolved. The solution is to append the DH parameters directly to the ssl cert file located in the /ssl directory of the EZProxy application, AND append them to the certification that appears in EZProxy Admin under Manage SSL. When appending the parameters to the cert, locate the number of the active cert (e.g., 00000015.crt, and add the parameters, which must include the BEGIN DH PARAMETERS and END DH PARAMETERS lines. Save and restart EZProxy, and you should be good to go.
Upvotes: 1