Re: Problem using FIPS with PKI

Arshad Noor <arshad.noor-NeRrhQ6gTz/qlBn2x/[email protected]> Sat, 30 Mar 2019 09:57:33 -0700
Newsgroups gmane.comp.encryption.bouncy-castle.devel
Organization StrongKey
Message-ID <[email protected]>
Have you verified that the truststore.bcfks file not only contains the 
self-signed Root CA certificate of the chain you need to verify the 
client certificate, and that the truststore.bcfks file is in the precise 
directory JBoss needs to establish the TLS session?

I would troubleshoot this as follows:

 1.   Move the keystore.jks/truststore.jks and
    keystore.bcfks/truststore.bcfks files to other names temporarily
    from the folder you _think_ is being used by JBoss to start TLS;
 2. Start JBoss.  If it complains of starting TLS because it cannot find
    the JKS and BCFKS files, then you're in the right directory;
 3. Rename the keystore.bcfks and truststore.bcfks files to their
    original names;
 4. Restart JBoss.  If TLS starts and you're still failing ClientAuth
    (because of a missing trusted certificate, then you're missing
    either the self-signed or an intermediate certificate of the chain
    in your truststore.bcfks;
 5. Add them and confirm that they do exist by listing out the certs
    using /keytool/;
 6. Restart JBoss.  At this point TLS ClientAuth should work.  If it
    doesn't then you may need to turn on JBoss debugging at more
    granular levels to see what the TLS library is doing, as it performs
    certificate validation, to learn what it is complaining about. I'm
    assuming, at this point, that all the CA certs you have in the
    truststore are the correct ones that are part of the chain.  Be
    careful with assuming that the certificates are correct based on the
    Subject DN/IssuerDN - _unless_ the /SubjectKeyIdentifier//(SKI)/ of
    the Issuer and the /AuthorityKeyIdenfier (AKI)///// of the subject
    match (along with Subject DN of the issuer the Issuer DN of the
    subject), the chain will not be identical. This problem can arise if
    you've issued multiple certificates with the same DNs, or if there
    are expired certificates in the chain.

Arshad Noor
StrongKey


On 3/29/19 10:07 AM, Chris Webb wrote:
>
> Sorry, I should have been more clear with my initial question.
>
> I did create both a keystore and a truststore. If I reference a 
> truststore file that doesn’t exist keycloak presents a different 
> error. The only difference between the command used to create the 
> truststore vs the keystore is the “-srckeystore” and “-destkeystore” 
> arguments in the keytool command from my initial post. So, I did the 
> following (minus the paths and passwords):
>
> keytool -importkeystore -srckeystore keystore.jks -srcstoretype JKS 
> -srcstorepass <password> -destkeystore keystore.bcfks -deststoretype 
> BCFKS -deststorepass <password> -provider 
> org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider 
> -providerpath /path/to/jar/bc-fips-1.0.1.jar
>
> keytool -importkeystore -srckeystore truststore.jks -srcstoretype JKS 
> -srcstorepass <password> -destkeystore truststore.bcfks -deststoretype 
> BCFKS -deststorepass <password> -provider 
> org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider 
> -providerpath /path/to/jar/bc-fips-1.0.1.jar
>
> As I mentioned before, if I switch it back to using the original 
> keystore.jks and truststore.jks files I had created before, and update 
> the java.security file to remove “BCFIPS”, PKI will work as expected.
>
> v/r
>
> Chris Webb
>
> *From:*Arshad Noor <arshad.noor-NeRrhQ6gTz/qlBn2x/[email protected]>
> *Sent:* Friday, March 29, 2019 8:09 AM
> *To:* Christophe Webb <[email protected]>; [email protected]
> *Subject:* Re: [dev-crypto] Problem using FIPS with PKI
>
> If you did not get an error with the /keytool/ command, then the files 
> were created correctly.
>
> There are usually three problems with /keytool/ many people stumble on:
>
>   * The keystore and truststore are two different files.  You've shown
>     the command to import the keys into the keystore in your e-mail,
>     but not the corresponding command to create the truststore.  The
>     trusted certificate the logs are complaining about, is in the
>     truststore.  I trust (sorry for the pun) you created the
>     truststore similarly;
>   * /keytool/ silently creates a new keystore/truststore in the _local
>     directory _without complaining, as long as the command parameters
>     are correct. Application servers use their keystores/truststores
>     only from certain configuration folders.  If the BCFKS file you
>     created is not in the folder your application server expects, its
>     most likely using the original truststore  - which probably does
>     not have the trusted CA certificate you needed to import for TLS
>     ClientAuth to work.  confirm that the truststore your application
>     server is using has a timestamp equivalent to the time you created
>     the truststore; to be absolutely certain, list the certificates
>     from your truststore to confirm that your trusted self-signed CA's
>     certificate is in there;
>   * The last problem is that the truststore does not have the precise
>     self-signed CA certificate, or intermediate CA certificates, for
>     the specific Client certificate you're using to perform client
>     authentication. Verify that you have the chain in the _keystore_
>     (at least up to the self-signed Root CA certificate) and the
>     self-signed Root CA certificate in the _truststore_.
>
> Arshad Noor
> StrongKey
>
> On 3/27/19 12:06 PM, Christophe Webb wrote:
>
>     I am running keycloak in a docker container. We are using PKI as
>     one of the authentication methods for our applications. I followed
>     the instructions for keycloak(X.509 Client Certificate User
>     Authentication) to set this up, and everything seems to work.
>     Next, we needed to update keycloak to be FIPS compliant. For this,
>     we are using the bouncy castle FIPS provider(bc-fips-1.0.1.jar). I
>     have set up the java.security file to make the bouncy castle fips
>     provider the default. This all works correctly as well.
>
>     However, once I update the java.security file to use
>     "com.sun.net.ssl.internal.ssl.Provider BCFIPS", PKI no longer
>     works. Regular SSL with out a client certificate provided works
>     just fine, and we can log in with username and password, but we
>     need PKI.
>     I have updated the keycloak standalone.xml with the following:
>     <server-identities>
>     <ssl>
>     <keystore provider="BCFKS" path="keystore.bcfks"
>     relative-to="jboss.server.config.dir"
>     keystore-password="<password>" alias="keycloak"
>     key-password="<password>"/>
>     </ssl>
>     </server-identities>
>     <authentication>
>     <truststore provider="BCFKS" *path="truststore.bcfks"
>     *relative-to="jboss.server.config.dir"
>     keystore-password="<password>"/>
>     <local default-user="$local" allowed-users="*"
>     skip-group-loading="true"/>
>     <properties path="application-users.properties"
>     relative-to="jboss.server.config.dir"/>
>     </authentication>
>
>     I took the JKS files for the keystore and truststore that I was
>     using before and imported them to BCFKS files using this basic
>     command:
>     keytool -importkeystore -srckeystore keystore.jks -srcstoretype
>     JKS -srcstorepass <password> -destkeystore keystore.bcfks
>     -deststoretype BCFKS -deststorepass <password> -provider
>     org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
>     -providerpath /path/to/jar/bc-fips-1.0.1.jar
>
>     I also updated the JAVA_OPTS to include -Djavax.net.debug=ssl. In
>     the output, I can see that my certificate is provided, and it
>     looks correct.
>
>     In the log output after the client certificate is logged, I see
>     the the following log statements.
>
>     14:38:30,927 INFO [stdout] (default task-1) default task-1, fatal
>     error: 46: General SSLEngine problem
>     14:38:30,927 INFO [stdout] (default task-1)
>     sun.security.validator.ValidatorException: *No trusted certificate
>     found*
>     14:38:30,927 INFO [stdout] (default task-1) %% Invalidated:
>     [Session-2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
>     14:38:30,927 INFO [stdout] (default task-1) default task-1, SEND
>     TLSv1.2 ALERT: fatal, description = certificate_unknown
>     14:38:30,927 INFO [stdout] (default task-1) default task-1, WRITE:
>     TLSv1.2 Alert, length = 2
>     14:38:30,928 INFO [stdout] (default I/O-2) default I/O-2, fatal:
>     engine already closed. Rethrowing
>     javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>     14:38:30,928 INFO [stdout] (default I/O-2) default I/O-2, called
>     closeInbound()
>     14:38:30,928 INFO [stdout] (default I/O-2) default I/O-2, fatal:
>     engine already closed. Rethrowing javax.net.ssl.SSLException:
>     Inbound closed before receiving peer's close_notify: possible
>     truncation attack?
>     14:38:30,928 INFO [stdout] (default I/O-2) default I/O-2, called
>     closeOutbound()
>     14:38:30,928 INFO [stdout] (default I/O-2) default I/O-2,
>     closeOutboundInternal()
>
>     Is it possible that I created the BCFKS keystore and truststore
>     incorrectly? If I switch back to the jks files, PKI works without
>     issue.
>
> Image removed by sender. 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> 	
>
> Virus-free. www.avg.com 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>