1 Reply Latest reply on Apr 9, 2020 7:43 AM by GTO455

    Certificate Issues with UAG

    GTO455 Enthusiast

      Hey Folks,


      I'm trying to set up a UAG (3.9.1) for my users. In our environment we use smart cards, so I am attempting to configure X.509 and it is failing. If the UAG is configured with Username/Password it works fine.


      I have a cert from external CA in "crt" format. Following the UAG Guide and setting up SAML, I am trying to convert the cert to one line PEM format and I dont know if I am doing this correctly.


      The doc says:

      If your certificate is in PKCS#12 (.p12 or .pfx) format, or after the certificate is converted to PKCS#12 format, use openssl to convert the certificate to .pem files.

      For example, if the name of the certificate is mycaservercert.pfx, use the following commands to convert the certificate:


      openssl pkcs12 -in mycaservercert.pfx -nokeys -out mycaservercert.pem

      openssl pkcs12 -in mycaservercert.pfx -nodes -nocerts -out mycaservercertkey.pem

      openssl rsa -in mycaservercertkey.pem -check -out mycaservercertkeyrsa.pem


      In my case the cert I received was in "crt" format from the CA, so I converted it to "pfx" format using openssl;

      openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt


      Once the file was converted to pfx, I ran the commands as described above and created the 3 files. Then I converted them to one line PEM format as the doc says to do using the awk command.


      However, when I went to configure the SAML settings in the UAG and uploaded the private keyfile I get the following error;

      Invalid PEM format. Exception message: -----END RSA PRIVATE KEY not found


      I checked the file in Notepad++ and it is clearly there. I even tried removing the trailing "\n" but it made no difference.

      I even tried uploading the normal PEM cert files (I read somewhere recently that single single conversion is no longer needed). The UAG accepts them, but authentication still fails when attempting to log in. Checking the authbroker.log file in the UAG, I found this line...


      Caused by: java.io.IOException: -----END RSA PRIVATE KEY not found


      I'm kinda stumped at this point. Can anyone offer any advice?






        • 1. Re: Certificate Issues with UAG
          GTO455 Enthusiast

          I found a solution to this error and hopefully responding to my own post will save someone else a lot of time resolving this issue.


          Working with VMware support to resolve the original issue, the certificate in question was imported to our Connection Server (as a pfx) and exported (with private key). Again the file was converted to PEM using the VMware recommended process. However, this time when the file was uploaded to UAG, the upload completely successfully. I should mention, this was all completed (cert creation, PFX and PEM conversions) on my Windows 10 workstation using OpenSSL for Windows 1.1.0h.

          Several attempts to authenticate through the UAG after the certificate was uploaded were unsuccessful. The esmanager.log file on the UAG Appliance generated ambiguous errors related to SSL; "SSL peer unverified," "a server error occurred, "Auth method(s) failed and no more auth method. Hence sending error", etc. The clients would generate an "HTTP 500 Error" or something similar with no additional information provided in the Horizon Client logs.

          A review of the authbroker.log again in the log bundle gave a more detailed list of the errors that were occurring, and it indicated that the formatting of the certificate was still not correct;

          Caused by: java.io.IOException: -----END RSA PRIVATE KEY not found
          at org.bouncycastle.util.io.pem.PemReader.loadObject(Unknown Source) ~[bc-fips-1.0.1.BC-FIPS-Certified.jar:?]
          at org.bouncycastle.util.io.pem.PemReader.readPemObject(Unknown Source) ~[bc-fips-1.0.1.BC-FIPS-Certified.jar:?]
          at org.bouncycastle.openssl.PEMParser.readObject(Unknown Source) ~[bcpkix-fips-1.0.1.BC-FIPS-Certified.jar:?]
          at com.vmware.horizon.pki.util.CertUtilities.parsePemKeyPair(CertUtilities.java:168) ~[pki-util-1.0.3-SNAPSHOT.jar:?]
          at com.vmware.horizon.auth.saml.SamlUtils.parsePemKey(SamlUtils.java:142) ~[auth-0.1.jar: Build 15502557]
          ... 80 more
          04/01 14:06:59,047[tomcat-http--10]ERROR mapper.AbstractExceptionMapper: Exception while handling jersey request.
          com.vmware.horizon.common.api.exception.InternalErrorException: error.spMetadataXml.readError
          at com.vmware.horizon.connector.restapi.identity.resource.authbroker.apiauth.APIAuthResource.prepareSamlResponse(APIAuthResource.java:268) ~[APIAuthResource.class:?]
          at com.vmware.horizon.connector.restapi.identity.resource.authbroker.apiauth.APIAuthResource.doAuthentication(APIAuthResource.java:215) ~[APIAuthResource.class:?]
          at com.vmware.horizon.connector.restapi.identity.resource.authbroker.apiauth.APIAuthResource.submitAuthentication(APIAuthResource.java:142) ~[APIAuthResource.class:?]
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_241]
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_241]
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_241]
          at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_241]

          So although the UAG Admin GUI said the certificate upload was successful, it really wasn't.

          Further searching on the Internet for a resoultion found this seemingly unrelated VMware KB article. However, following the directions in the article, the certificate was uploaded to the UAG appliance and converted using the following command in the CLI;

          openssl rsa -in original_key.pem -out new_key.pem

          The certificate was then re-deployed, certificate re-installed, new SAML information generated, and the server began accepting smart card PIN and authenticating users.

          I guess the moral of the story is to do all your openssl certificate creation, conversion on the UAG appliance, or at least use a version of Openssl that is the same as the appliance you are deploying.