Hi, Valsaraj. 1. Have you tried to use `1.3.6.1.4.1.1466.115.121.1.5` syntax insteado `1.8` (certificate) in schema? 2. Have you modified `/etc/gluu/conf/ox-ldap.properties` as well, as, for example, shown in [this doc](https://gluu.org/docs/ce/3.1.0/integration/saas/office/#idp-configuration)?

Valsaraj, Thanks for testing this? Can you paste a sample ldif file so we can try to duplicate your error? - Mike

Hi Aliaksandr Samuseu, Got following error when we tries step #1. We are using OpenLDAP with Gluu. > Have you tried to use 1.3.6.1.4.1.1466.115.121.1.5 syntax instead of 1.8 (certificate) in schema? > AttributeType inappropriate matching rule: "certificateExa > ctMatch" Tried step #2 > Have you modified /etc/gluu/conf/ox-ldap.properties as well, as, for example, shown in this doc? This didn't fix the issue & same error shown.

Is this existing issue in Gluu code for cache refresh? Ref: [https://bugs.openjdk.java.net/browse/JDK-4296974](https://bugs.openjdk.java.net/browse/JDK-4296974) [https://issues.apache.org/jira/browse/DIRSTUDIO-1108](https://issues.apache.org/jira/browse/DIRSTUDIO-1108)

Hi Aliaksandr Samuseu, We can able to manually import userCertificate to inum ldap server but also unable view the userCertificate in the Gluu server. The bellow is while gluu try to update userCertificate from the ldap backend. ``` 2017-10-11 10:43:29,858 ERROR [ForkJoinPool.commonPool-worker-0] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:684) - Failed to 'update' person '@!846A.617B.C89F.18CD!0001!4118.D484!0000!0368.8AC5' org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to update entry: inum=@!846A.617B.C89F.18CD!0001!4118.D484!0000!0368.8AC5,ou=people,o=@!846A.617B.C89F.18CD!0001!4118.D484,o=gluu Caused by: com.unboundid.ldap.sdk.LDAPException: userCertificate;binary: value #0 invalid per syntax at com.unboundid.ldap.sdk.LDAPConnection.modify(LDAPConnection.java:2754) ~[unboundid-ldapsdk-3.2.0.jar:3.2.0] ```

Hi, Valsaraj, Anandbabu. Yes, I've also come to the conclusion that it has something to do with [binary transfer](https://tools.ietf.org/html/rfc4522). Seems like current Gluu's LDAP handling code doesn't use that option when trying to write certificate to an attribute. Thanks for sharing your findings, I'll proceed to creating bug report so it could be fixed.

Hi Michael, Have you tried with the input sample that I shared? Hi Aliaksandr Samuseu, Can we expect the fix soon? Thanks!

I'll assign the issue for more research.

Valsaraj, Can you share how you mapped userCertificate for cache refresh?

I'm currently able to add entries manually by modifying my schema, restarting solserver and using ldap modify for a .ldif: ``` vi chris.ldif dn: inum=@!4F28.9AB9.686C.B2E5!0001!373A.FC53!0000!dc,ou=people,o=@!4F28.9AB9.686C.B2E5!0001!373A.FC53,o=gluu changetype: add oxCreationTimestamp: 20171013181917.088Z uid: afroDC givenName: Chris displayName: DC sn: Blanton mail: dc@gluu.org gluuStatus: active oxTrustEmail: {"operation":null,"value":"dc@gluu.org","display":"dc@gluu.org","p rimary":true,"reference":null,"type":"other"} inum: @!4F28.9AB9.686C.B2E5!0001!373A.FC53!0000!dc iname: *person*afroDC userPassword:: e0JDUllQVH0kMmIkMDgkbEt3QjRoeFdaaldYZklUdEZIRXhIdTZrTFVWNy5HZ1pWY khpcURyTE90R0d3RVJMSWxtd2UA usercertificate:: MIICOzCCAaSgAwIBAgIIG4PzK/izWnowDQYJKoZIhvcNAQEFBQA wYDFeMAkGA1UEBhMCVVMwCQYDVQQIEwJLTDAOBgNVBAoTB0N5cnVzeHAwDgYDVQQLEwdDeXJ1c3 hwMBIGA1UEAxMLQW5hbmRiYWJ1IFYwEgYJKoZIhvcNAQkBFgVhbmFuZDAeFw0xNTA5MjExMTUxN TBaFw00NzA1MzAxMzM4MzBaMGAxXjAJBgNVBAYTAlVTMAkGA1UECBMCS0wwDgYDVQQKEwdDeXJ1 c3hwMA4GA1UECxMHQ3lydXN4cDASBgNVBAMTC0FuYW5kYmFidSBWMBIGCSqGSIb3DQEJARYFYW5 hbmQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIS+XfAHIQPhuBb6RnpFyDElS1O0dj7Sxb fYqspQzevqQYQs2QsAqodD79sNc6yErB4+Uj7yxZE7SFhJ3/c3e6vGvNL8gfJVL31tnBN1iI8rG tpjl3Et1imS+AlmZHRkUWE0d7xrxd2D53dgOcJXPUFsUaLUfzaPGs9FPdbUVrgHAgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEALWx0ok3k2fS439QgFWWYqFWfaS83Qq8mGOt8VBIDYLY06CDHUQrqKaW Aij2hJeTYrYLecoCa6WxrDXAy4m+y99qBRaP0pJyYTkeR6hsQbQomIsST9fTPaI42j50hy3WeLm dN86Vmv+SFjAniyOhmrPjPkV000k95mo6PYKWEkqw= cn: Chris DC objectClass: top objectClass: gluuPerson objectClass: gluuCustomPerson objectClass: eduPerson [root@localhost ~]# /opt/opendj/bin/ldapmodify -p 1636 -Z -X -D "cn=directory manager,o=gluu" -w secret -f chris.ldif [root@localhost ~]# /opt/opendj/bin/ldapsearch -p 1636 -Z -X -D 'cn=directory manager,o=gluu' -w secret -b o=gluu "cn=*" dn: inum=@!4F28.9AB9.686C.B2E5!0001!373A.FC53!0000!dc,ou=people,o=@!4F28.9AB9.68 6C.B2E5!0001!373A.FC53,o=gluu mail: dc@gluu.org iname: *person*afroDC displayName: DC givenName: Chris sn: Blanton cn: Chris DC oxCreationTimestamp: 20171013181917.088Z objectClass: top objectClass: eduPerson objectClass: gluuPerson objectClass: gluuCustomPerson userCertificate;binary:: MIICOzCCAaSgAwIBAgIIG4PzK/izWnowDQYJKoZIhvcNAQEFBQAwYDF eMAkGA1UEBhMCVVMwCQYDVQQIEwJLTDAOBgNVBAoTB0N5cnVzeHAwDgYDVQQLEwdDeXJ1c3hwMBIGA1 UEAxMLQW5hbmRiYWJ1IFYwEgYJKoZIhvcNAQkBFgVhbmFuZDAeFw0xNTA5MjExMTUxNTBaFw00NzA1M zAxMzM4MzBaMGAxXjAJBgNVBAYTAlVTMAkGA1UECBMCS0wwDgYDVQQKEwdDeXJ1c3hwMA4GA1UECxMH Q3lydXN4cDASBgNVBAMTC0FuYW5kYmFidSBWMBIGCSqGSIb3DQEJARYFYW5hbmQwgZ8wDQYJKoZIhvc NAQEBBQADgY0AMIGJAoGBAIS+XfAHIQPhuBb6RnpFyDElS1O0dj7SxbfYqspQzevqQYQs2QsAqodD79 sNc6yErB4+Uj7yxZE7SFhJ3/c3e6vGvNL8gfJVL31tnBN1iI8rGtpjl3Et1imS+AlmZHRkUWE0d7xrx d2D53dgOcJXPUFsUaLUfzaPGs9FPdbUVrgHAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEALWx0ok3k2fS4 39QgFWWYqFWfaS83Qq8mGOt8VBIDYLY06CDHUQrqKaWAij2hJeTYrYLecoCa6WxrDXAy4m+y99qBRaP 0pJyYTkeR6hsQbQomIsST9fTPaI42j50hy3WeLmdN86Vmv+SFjAniyOhmrPjPkV000k95mo6PYKWEkq w= gluuStatus: active userPassword:: e0JDUllQVH0kMmIkMDgkbEt3QjRoeFdaaldYZklUdEZIRXhIdTZrTFVWNy5HZ1pWY khpcURyTE90R0d3RVJMSWxtd2UA oxTrustEmail: {"operation":null,"value":"dc@gluu.org","display":"dc@gluu.org","p rimary":true,"reference":null,"type":"other"} inum: @!4F28.9AB9.686C.B2E5!0001!373A.FC53!0000!dc uid: afroDC ``` Note the `usercertificate::` entry is changed to `usercertificate;binary::` automatically after beind added with ldapmodify. I'll look into this further.

Hi Chris, We are using OpenLDAP instead of OpenDJ. We have a source LDAP and we are using cache refresh feature of Gluu to load Gluu LDAP. We have mapped userCertificate in source LDAP with userCertificate type in Gluu. There is userCertificate attribute already in Gluu and we added that into gluuPerson as described in this ticket.

Hello Chris, Please refer the ticket to add userCertificate in Gluu cacherefresh, Once the attribute is listed under gluuPerson we have to add the attribute in the cacheRefresh settings, [https://support.gluu.org/customization/4614/unable-to-add-custom-attribute/](https://support.gluu.org/customization/4614/unable-to-add-custom-attribute/#at26056)

Would you lease update whether any progress on this issue? It would be great if you can suggest fix, we can checkout source code & apply the fix. I got following URL: [https://github.com/GluuFederation/oxTrust.git](https://github.com/GluuFederation/oxTrust.git) Since we have installed gluu 3.1.1, we need to checkout 3.1.1 version of exTrust from repo and deploy that jar in Gluu server for checking?