I am having the same issue and have raised a Red Hat ticket. They told me to ask for an escalation on this so that it gets more attention. 

I am getting this issue when using this code as well:

import javax.crypto.spec.SecretKeySpec;
import javax.crypto.Mac;

public class HmacTest {

        private static final byte[] CLIENT_KEY_HMAC_KEY = "Client Key".getBytes();
        private static String HMAC_ALGORITHM_NAME = "HmacSHA256";

        public static void main (String[] args) {
            try {
                SecretKeySpec sKey = new SecretKeySpec(CLIENT_KEY_HMAC_KEY, HMAC_ALGORITHM_NAME);
                Mac mac = Mac.getInstance(HMAC_ALGORITHM_NAME);
                mac.init(sKey);
                System.out.println(mac.doFinal("message".getBytes()));
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
}

What is the full RPM version of the OpenJDK version where you're seeing this failure?

I think any jdk17 rpm should do. I think this probably never worked (at least not on NSS). Generators were added in JDK16.

Hmac* KeyGenerators were added in JDK16.

Just as an added note - this is the version of Java that we have installed:

java-17-openjdk-devel-17.0.3.0.7-2.el8_6.x86_64

Using the following in nss.fips.config makes this test pass:
attributes(generate,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true }

This is related to https://access.redhat.com/support/cases/03208568


If we combine that with the work belonging to Bug 2020290 (which does the same but for the 'import' operation instead of 'generate'), we should finally end up with:
attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true }


See https://docs.oracle.com/en/java/javase/17/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9__PKCS11-ATTRIBUTES-CONFIGURATION

Some clarifications
===================

 • Comment 0 reproducer uses the KeyGenerator service to create the key, so it involves the 'generate' operation
 • Comment 2 reproducer directly passes a SecretKeySpec, so it involves the 'import' operation, and it additionally requires Bug 1994661 work [*]
   • Additionally, this test fails with CKR_KEY_SIZE_RANGE because the key must be at least 16 bytes long due to FIPS restrictions

In OpenJDK 17, if I increase the key size of Comment 2 reproducer and add the following to nss.fips.cfg, both reproducers end without any errors:
attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true }

In OpenJDK 11 and OpenJDK 8, with the same addition to nss.fips.cfg, Comment 2 reproducer works (with a 16 bytes key). Comment 0 reproducer still fails with 'NoSuchAlgorithmException: HmacSHA256 KeyGenerator not available', due to the absence of JDK-8242332 work (as already mentioned).


[*]: As shown in the following stack for OpenJDK 17:
     [1]: sun.security.pkcs11.FIPSKeyImporter.importKey(FIPSKeyImporter.java:67)
          [...] java.lang.invoke.LambdaForm* [...]
     [2]: sun.security.pkcs11.wrapper.PKCS11$FIPSPKCS11.C_CreateObject(PKCS11.java:1970)
     [3]: sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:285)
     [4]: sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:191)
     [5]: sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:123)
     [6]: sun.security.pkcs11.P11Mac.engineInit(P11Mac.java:210)
     [7]: javax.crypto.Mac.chooseProvider(Mac.java:365)
     [8]: javax.crypto.Mac.init(Mac.java:434)

[1]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/FIPSKeyImporter.java#L67
[2]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java#L1970
[3]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L285
[4]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L191
[5]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L123
[6]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L210
[7]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/java.base/share/classes/javax/crypto/Mac.java#L365
[8]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/java.base/share/classes/javax/crypto/Mac.java#L434

Proposed equivalent Fedora pull request for the fix: https://src.fedoraproject.org/rpms/java-17-openjdk/pull-request/17#request_diff

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (java-17-openjdk bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:6691