How would we reproduce this? 1.8.0.91-1.b14 got some changes to crypto libs, but it's hard to tell from this stack trace only.

Eclipse hit it too:
https://paste.fedoraproject.org/358513/

Thats reproducible when you run eclipse updater

AFAIK jdk disabled few legacy algorithms, and when server can not use newer, then you got this exception. From top of my head, I'm now nto able to find them.

(In reply to jiri vanek from comment #3)
> Thats reproducible when you run eclipse updater

This doesn't exactly help. We'd need a https URL which works before and no longer works after. Then we should have a reproducer.

Reproducer:

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;

/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */


/**
 *
 * @author jvanek
 */
public class HttpsCheck {

    static String[] urls = {
    "https://bugzilla.redhat.com/",
    "https://dl.bintray.com/fabioz/pydev/4.5.5/",
    "https://hudson.eclipse.org/cdt/job/launchbar-master/lastSuccessfulBuild/artifact/repo/target/repository"};
    
            public static void main(String[] args) throws Exception{
                for (String url : urls) {
                    URL u = new URL(url);
                    InputStream is = u.openStream();
                    BufferedReader bw = new BufferedReader(new InputStreamReader(is,"utf8"));
                    StringBuilder page = new StringBuilder();
                    while(true){
                        String s = bw.readLine();
                        if (s == null){
                            break;
                        }
                        page.append(s);
                    }
                    System.out.println(page.toString());
                }
    }
    
}

https://java.com/en/download/faq/release_changes.xml is mentioning only  MD5withRSA may it be so widespread?

java.security file is same as in u77

fyi:
https://bugs.gentoo.org/show_bug.cgi?id=579676#c6
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2934

However, the mentioned test IS included
http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n817
run
http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1390
and 
according to logs:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13734068

passed

(In reply to jiri vanek from comment #13)
> However, the mentioned test IS included
> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.
> 0-openjdk.spec#n817

ah.. is NOT run

> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.
> 0-openjdk.spec#n1390
> and 
> according to logs:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13734068

It fails in EC_NewKey() on line 124[1] which in turn fails in ec_GenerateRandomPrivateKey()[2] which returns NULL:

    // Generate the new keypair (using the supplied seed)
    if (EC_NewKey(ecparams, &privKey, (unsigned char *) pSeedBuffer,
        jSeedLength, 0) != SECSuccess) {
        ThrowException(env, KEY_EXCEPTION);
        goto cleanup;
    }

[1] http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/file/0e757f8bf24c/src/share/native/sun/security/ec/ECC_JNI.cpp#l124
[2] http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/file/0e757f8bf24c/src/share/native/sun/security/ec/impl/ec.c#l383

Sorry wrong sources. Those functions come from system nss, not openjdk. Can't find the links :(

Here they are:
[1] https://hg.mozilla.org/projects/nss/file/NSS_3_23_RTM/lib/freebl/ec.c#l391
[2] https://hg.mozilla.org/projects/nss/file/NSS_3_23_RTM/lib/freebl/ec.c#l342

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2934

I suggest removing Alex's patch for now:

Patch517: pr2899.patch

until we have a proper resolution. 

There is a test for this in the RPM. I suspect the disabling of this test has been wrongly synced across from RHEL 7.3 (which hasn't shipped yet) to Fedora.

Ok, try this:

http://icedtea.classpath.org/hg/release/icedtea8-forest-3.0/jdk/rev/dab76de2f91c

It makes the ECDSATest pass locally.

$ /mnt/builder/icedtea-3.0/images/j2sdk-image/bin/java ECDSATest
Signature: 3046022100afd27e5b82c3b3e607e4a0568691e1e817672e45ed1f7f1f62f2273ad021aa8b0221008aceea3a84a688426aa34151c1d5abb385250d6fdfdd47c02f5a7c694d9939c1
Test passed.

In reply to Andrew John Hughes from comment #19)
> Ok, try this:
> 
> http://icedtea.classpath.org/hg/release/icedtea8-forest-3.0/jdk/rev/
> dab76de2f91c

I tried a scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13764668

The new patch being applied in the build log:

Patch #518 (pr2934-system-nss.patch):
+ echo 'Patch #518 (pr2934-system-nss.patch):'
+ /usr/bin/patch -p0 --fuzz=0
patching file openjdk/jdk/src/share/native/sun/security/ec/ECC_JNI.cpp
patching file openjdk/jdk/src/share/native/sun/security/ec/ecc_impl.h

The test result from the build log:
+ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/build/jdk8.build/images/j2sdk-image/bin/javac -d . /builddir/build/SOURCES/TestECDSA.java
++ sed 's|\.java||'
+++ basename /builddir/build/SOURCES/TestECDSA.java
++ echo TestECDSA.java
+ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/build/jdk8.build/images/j2sdk-image/bin/java TestECDSA
Signature: 30460221008358fef430add1b9d4b0aa7c1ddf846b23271a9129c6d53b0127d9bbca4f3f46022100a2431012bf257898fe56a2e28032ccba521649ce67bb2c2b0536d998852e5b69
Test passed.

Should I add the patch in F22, F23, F24 and Rawhide?

I can confirm that scratch build gets zanata-cli working again here. ;)

> Should I add the patch in F22, F23, F24 and Rawhide?

Yeah, I've already added it in RHEL but can't commit to Fedora. Just backported the most recent rhel-7.3 changeset.

(In reply to Andrew John Hughes from comment #22)
> > Should I add the patch in F22, F23, F24 and Rawhide?
> 
> Yeah, I've already added it in RHEL but can't commit to Fedora. Just
> backported the most recent rhel-7.3 changeset.

'backport' even... sigh.

(In reply to Omair Majid from comment #20)
> In reply to Andrew John Hughes from comment #19)
> > Ok, try this:
> > 
> > http://icedtea.classpath.org/hg/release/icedtea8-forest-3.0/jdk/rev/
> > dab76de2f91c
> 
> I tried a scratch build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13764668
> 
> The new patch being applied in the build log:
> 
> Patch #518 (pr2934-system-nss.patch):
> + echo 'Patch #518 (pr2934-system-nss.patch):'
> + /usr/bin/patch -p0 --fuzz=0
> patching file openjdk/jdk/src/share/native/sun/security/ec/ECC_JNI.cpp
> patching file openjdk/jdk/src/share/native/sun/security/ec/ecc_impl.h
> 
> The test result from the build log:
> +
> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/
> build/jdk8.build/images/j2sdk-image/bin/javac -d .
> /builddir/build/SOURCES/TestECDSA.java
> ++ sed 's|\.java||'
> +++ basename /builddir/build/SOURCES/TestECDSA.java
> ++ echo TestECDSA.java
> +
> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/
> build/jdk8.build/images/j2sdk-image/bin/java TestECDSA
> Signature:
> 30460221008358fef430add1b9d4b0aa7c1ddf846b23271a9129c6d53b0127d9bbca4f3f46022
> 100a2431012bf257898fe56a2e28032ccba521649ce67bb2c2b0536d998852e5b69
> Test passed.
> 
> Should I add the patch in F22, F23, F24 and Rawhide?

Patch is applied  and test enabled  in f22-f25. builds running

java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f7c893042

java-1.8.0-openjdk-1.8.0.91-2.b14.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c283d0e78e

java-1.8.0-openjdk-1.8.0.91-2.b14.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5

*** Bug 1329909 has been marked as a duplicate of this bug. ***

FEDORA-2016-9f5172b1c5 fixed duplicate bug 1329909

java-1.8.0-openjdk-1.8.0.91-2.b14.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c283d0e78e

java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f7c893042

*** Bug 1330163 has been marked as a duplicate of this bug. ***

java-1.8.0-openjdk-1.8.0.91-2.b14.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5

java-1.8.0-openjdk-1.8.0.91-2.b14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Reopening for f24

Hello, please push ​https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5 to stable. java-1.8.0-openjdk-1.8.0.91-1.b14.fc24 was nearly uusable, and -2. is fixing the issue (As seen form karmas for f23 and also f24

(In reply to jiri vanek from comment #37)
> Hello, please push
> ​https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5 to stable.
> java-1.8.0-openjdk-1.8.0.91-1.b14.fc24 was nearly uusable, and -2. is fixing
> the issue (As seen form karmas for f23 and also f24

More verbose - this update is fixin bug in previous update which is making most https connections broken. So any java deplyment (tomcat and spol) canbe moreover considered as dead. 
Of course also client apps like sqriell or similar are doomed with https.

We have openjdk on Workstation Live, libreoffice depends on it (not sure whether libreoffice uses java for accessing https urls). We also have openjdk in Server repo, but after installation it is not installed, so Server doesn't seem to depend on it.

(In reply to Kamil Páral from comment #39)
> We also have
> openjdk in Server repo, but after installation it is not installed, so
> Server doesn't seem to depend on it.

I was wrong, I forgot to install all addons. If you install all addons, there are many things depending on openjdk, like tomcat, pki-ca, freeipa-server, glassfish, etc.

Most of those addons  may suffer by this issue.

This was not considered as a blocker because the dependency was done the wrong way round - this bug was set to *depend on* the tracker, rather than block it. Fixing.

+1 FE, I am not sure what blocking criteria it violates, but would be good to fix

I'm also +1 FE; I don't quite see it hitting a release criteria.

It's fixed as far as I know.

https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5

That update is in updates-testing, which means it would not be included in Beta composes. The blocker/freeze exception review process exists to decide what fixes *must* and *can* be pushed to stable and included in composes during the freeze period. That is what we're voting about.

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

I also am +1 FE, -1 Blocker, +1 Final blocker. The relevant criterion is Final:

"The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)." - https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Security_bugs

there is no corresponding Beta criterion. That's +3 FE, -3 blocker, so setting that status.

Discussed during the 2016-05-02 blocker review meeting.

The decision on final blocker status has been delayed because we expect this to be closed soon as the fix was included in the last beta compose as an FE and the update has sufficient karma to be pushed stable.

java-1.8.0-openjdk-1.8.0.91-2.b14.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Is this problem also fixed in RedHat Server versions? How can i figure this out? Thanks for helping.

Yes, see comment #22.

Andrew thanks for your time, i apologize already in advance but I've got no clue how to figure out in which patch of RHEL this bug is fixed. We have experienced this on one of our systems months ago and are unsure which version we have to upgrade to in order to resolve this.

In Fedora i would assume from what i can read from this bug report that it was fixed immediately. Is it the same in Redhat? (they cycle packages slower right?)

RHEL java-1.8.0-openjdk packages are updated at least four times a year for the security updates (Jan, Apr, Jul and Oct). The Fedora packages feed from the RHEL ones, though that includes stuff for the next RHEL releases, so it will appear in Fedora first, even though it was applied to RHEL spec file beforehand (if that make sense).

There is no ECC support yet in RHEL 7. This is coming with RHEL 7.3, where this patch has been applied.

For RHEL 6, ECC support appeared in RHEL 6.8 but it seems this patch hasn't yet been included, which I hadn't realised until now, so thanks for raising this. I'll make sure that gets in for the January update at the latest.

Hope that helps.

Thank you Andrew, that clears up my picture. We have 6.8 so that makes totally sense. We will check in January for the package.

(In reply to Andrew John Hughes from comment #53)
> RHEL java-1.8.0-openjdk packages are updated at least four times a year for
> the security updates (Jan, Apr, Jul and Oct). The Fedora packages feed from
> the RHEL ones, though that includes stuff for the next RHEL releases, so it
> will appear in Fedora first, even though it was applied to RHEL spec file
> beforehand (if that make sense).
> 
> There is no ECC support yet in RHEL 7. This is coming with RHEL 7.3, where
> this patch has been applied.
> 
> For RHEL 6, ECC support appeared in RHEL 6.8 but it seems this patch hasn't
> yet been included, which I hadn't realised until now, so thanks for raising
> this. I'll make sure that gets in for the January update at the latest.
> 
> Hope that helps.

Thank you Andrew for the info.

Currently several of our redhat servers can only support TLS_RSA* ciphers. Our security has flagged with several vulnerabilities.

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.x86_64/jre/lib/security/java.security

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC, ECDHE, ECDH

Not sure how other enterprise installs are dealing without ECC in openjdk8?

I removed last three ciphers in the above disabled list and put below config and it seems to work with limited testing and no errors in catalina. Our team is pondering over this workaround on a production systems.

sslEnabledProtocols="TLSv1.2"
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA

256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECD

H_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_A

ES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS

_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CB

C_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

(In reply to daba from comment #55)
> (In reply to Andrew John Hughes from comment #53)
> > RHEL java-1.8.0-openjdk packages are updated at least four times a year for
> > the security updates (Jan, Apr, Jul and Oct). The Fedora packages feed from
> > the RHEL ones, though that includes stuff for the next RHEL releases, so it
> > will appear in Fedora first, even though it was applied to RHEL spec file
> > beforehand (if that make sense).
> > 
> > There is no ECC support yet in RHEL 7. This is coming with RHEL 7.3, where
> > this patch has been applied.
> > 
> > For RHEL 6, ECC support appeared in RHEL 6.8 but it seems this patch hasn't
> > yet been included, which I hadn't realised until now, so thanks for raising
> > this. I'll make sure that gets in for the January update at the latest.
> > 
> > Hope that helps.
> 
> Thank you Andrew for the info.
> 
> Currently several of our redhat servers can only support TLS_RSA* ciphers.
> Our security has flagged with several vulnerabilities.
> 
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.x86_64/jre/lib/
> security/java.security
> 
> jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC,
> ECDHE, ECDH
> 
> Not sure how other enterprise installs are dealing without ECC in openjdk8?
> 
> I removed last three ciphers in the above disabled list and put below config
> and it seems to work with limited testing and no errors in catalina. Our
> team is pondering over this workaround on a production systems.
> 
> sslEnabledProtocols="TLSv1.2"
> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA
> 
> 256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECD
> 
> H_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_A
> 
> ES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS
> 
> _DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_256_CB
> 
> C_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

Sorry....just got report that above ciphers are failing on several machines so the workaround is useless. Back to square one of only using TLS_RSA*ciphers.

On RHEL 7.2, EC, ECDHE and ECDH are disabled because there is no elliptic curve cryptography provider. Enabling them won't magically make one appear. This is resolved in RHEL 7.3.

Major additions like this need sufficient testing, so can only really happen in feature releases.

Andrew, with yum update  we got openjdk-1.8.0.111-2.b15.el7_3.x86_64 over existing openjdk-1.8.0.111-1.b15.el7_2.x86_64.  After restart the issue persisted.

Noticed ..usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/lib/security has two files….

java.security --jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC, ECDHE, ECDH

java.security.rpmnew -- jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768


I made the .rpmnew as the java.security file...and this seems to have fixed the issue. Chrome on windows reports "The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA), and a strong cipher (AES_256_GCM)". 

Are the changes expected for java.security.rpmnew to enable ECC instead of out of the box RHEL 7.3 update?

Thank you!

java.security.rpmnew is what should be used and it should have been automatically copied over, if java.security was unchanged.

However, this hasn't happened in this case. It seems to be a consequence of the security update for RHEL 7.2 being applied. The 7.3 RPM was actually produced first, so it isn't aware of the checksum used in the RHEL 7.2 security RPM and so it can't determine that the java.security file you have installed from that RPM is an unchanged RPM copy rather than one you've modified yourself.

The next update will make sure that the 7.2 one is replaced by the version from the 7.3 RPM, but for now, it will have to be manually copied over, as you did.