EZproxy Security FAQ

The following FAQ provide details about EZproxy V5.7.44 and before. For the most up-to-date information on EZproxy security issues, see EZproxy & OpenSSL and SSL Configuration.

There are many SSL/TLS-related configuration options in EZproxy. When do I use Option EnableSSLv3, Option DisableSSLv2, and SSLCipherSuite?

By default, EZproxy V5.7.44 disables SSL 3 and enables SSL2; however it also supports TLS 1.0. These config.txt statements control the SSL/TLS options your instance of EZproxy will use.

Option EnableSSLv3

SSL 2 and SSL 3 are older protocol definitions that normally should not be used. We provide the ability to use them since some legacy environments may need them. If you are using an environment that requires SSL 3, you can force EZproxy to use this protocol by entering the following statement before an LoginPortSSL statements in your config.txt file:

Option EnableSSLv3

For more details on SSL 2 and SSL 3, please see http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0. This article also describes transport level security (TLS), the successor to SSL 2 and SSL 3.

Option DisableSSLv2

By default, EZproxy V5.7.44 disables SSL 3 and enables SSL 2. Because EZproxy V5.7.44 supports TLS 1.0 for client to webserver interactions, OCLC recommends that you also disable SSL 2 in addition to the default-disabled SSL 3.To do this, place the following statement before any LoginPortSSL statements in your config.txt file:

Option DisableSSLv2

After disabling SSL 2 and retaining the default setting of disabled SSL 3, your EZproxy will default to TLS 1.0.

EZproxy V6.0 will have the same SSL/TLS settings as V5.7.44. EZproxy V6.1 will be built with OpenSSL V1.x, and we plan to support TLS 1.1 and 1.2 with this build. EZproxy 6.1 will disable both SSL 3 and SSL 2 by default.  


SSLCipherSuite offers finer grain control over SSL/TLS options. We use OpenSSL as our security library layer, and SSLCipherSuite options are passed directly to OpenSSL for processing. EZproxy V5.7.44 supports all of the cipher settings defined by https://www.openssl.org/docs/man1.0.2/apps/ciphers.html#CIPHER-STRINGS.

SSLCipherSuite was introduced with the first V5.7 release. OCLC recommends updating to V5.7.44 if you use SSLCipherSuite. For more details about how to use SSLCipherSuite, see FAQ 2: Give me some details on SSLCipherSuite.

Give me some details on SSLCipherSuite

If SSLCipherSuite is present in config.txt, and no values are defined for this directive, EZproxy defaults to the values:


The table below provides additional directives that influence the SSLCipherSuite string.

Directive Values Appended to Default
Option DisableSSL56bit
Option DisableSSL40bit

Option DisableSSL40bit
Option DisableSSLv2


After any of the above changes are applied, EZproxy always appends to the default string:


What DES encryption options does EZproxy offer?

EZproxy supports, 40 bit encryption, 56 bit encryption, and 128, 192 and 256 bit AES encryption. Encryption keys define the size of the cipher used to encrypt data transmitted via SSL/TLS over https: connections.

40 and 56 bit encryption should be disabled by default; however, OCLC provides 40 and 56 bit encryption for legacy purposes. OCLC recommends that you disable 40 and 56 bit encryption unless you have specific legacy requirements.

To disable 40 bit encryption, add the following statement to your config.txt file:

Option DisableSSL40bit

To disable 56 bit encryption, add the following statement to your config.txt file:

Option DisableSSL56bit

OCLC will disable 40 bit encryption by default in release 6.1.

Describe EZproxy and wildcard SSL certificates.

If you are using Proxy by Port, you do not need a wildcard certificate.

If you use Proxy by Host, this information is relevant to your implementation.

  1. EZproxy currently does not use the SAN field when looking for domains. The EZproxy domain *must* be the in the CN field.  If your EZproxy server is ezproxy.college.edu, then the name in the CN field must be *.ezproxy.college.edu. EZproxy does not validate the entire CN field, but looks for the presence of a “*.” at the beginning of this field. The certificate, however, must have the correct name, or you will receive browser warnings and other error messages.

  2. The non-wildcard domain must be in the SAN field, or you will receive browser messages in some cases. If the CN field entry is *.ezproxy.college.edu, then the SAN field needs to have an entry of ezproxy.college.edu.

  3. We have an improvement planned that will add an option, Option ForceWildCardCertificate, to tell EZproxy that the certificate is a valid wildcard certificate. Again, the certificate MUST have, either in the CN or the SAN fields, the proper wildcard name in order to avoid browser error messages. Using the example above, the proper name is *.ezproxy.colleage.edu. This improvement is planned for EZproxy V6.1.

  4. Make sure all EZproxy URLs that are in websites or publicized to users are using this syntax (assume the EZproxy server name is ezproxy.college.edu, and the content site is somedb.com):
  5. http://ezproxy.college.edu/login?url=http://somedb.com/

If the rules above are implemented, using this format will ensure that there are no certificate errors when accessing EZproxy.