4

We have two active directory (AD) hosts, ead01.domain.com and ead02.domain.com; we also have a corresponding service domain, at eadauth.domain.com which round-robins between these AD hosts (via DNS).

We have a ColdFusion application (CF runs on Java) that connects to the service domain over secure port 636. After upgrading our version of Java to 1.60_91 from 1.6.0_81, SSL handshakes now occasionally return this error:

jrpp-83, SEND TLSv1 ALERT:  fatal, description = bad_certificate
jrpp-83, WRITE: TLSv1 Alert, length = 2
jrpp-83, called closeSocket()
jrpp-83, handling exception: javax.net.ssl.SSLHandshakeException: server certificate change is restricted during renegotiation

Unsafe Renegotiation was disabled in 1.6.0_85.

ead01.domain.com has a SAN cert with these entries

SubjectAlternativeName [
  DNSName: ead01.domain.com
  DNSName: eadauth.domain.com
]

and ead02.domain.com has:

SubjectAlternativeName [
  DNSName: ead02.domain.com
  DNSName: eadauth.domain.com
]

My questions are: Should we generate and bind one new cert with SANs as follows on both hosts?

SubjectAlternativeName [
  DNSName: ead01.domain.com
  DNSName: ead02.domain.com
  DNSName: eadauth.domain.com
]

Are there any down sides to this setup? Any other options that we might consider, other than disabling unsafe renegotiation?

KM.
  • 161
  • 2
  • 5
  • 1
    Since Java 1.6 reached no-more-updates end-of-life _2 years ago_, maybe you should see how 1.7 and 1.8 behave before changing your certificate setup? You're going to have to upgrade to them within another 3 or 4 years no matter what. – gowenfawr Mar 05 '15 at 22:02
  • @gowenfawr Java 1.7.0_71 and 1.8.0_25 do away with unsafe renegotiation too. Wondering, if it be possible to disable renegotiation on the server or even on the client? – KM. Mar 06 '15 at 00:36

0 Answers0