1. We have the cmdlet that caused the error New-SendConnector.
2. We have the same attribute (msExchSmtpTLSCertificate):len 552
3. And we have the famous error of the cmdlet has thrown an exception.
- Issuer: this field shows the name of the Certificate Authority (CA) who issued the certificate, and as you can see Comodo has a very long name compared with other CAs.
- Subject: this field shows information like Organization (O), Country (C), Common Name (CN). And again as you can see from the marked field in the snapshot the customer was using a very long name.
1. Use user account that member of Schema Admins and Enterprise Admins.
2. Open adsiedit.msc
3. Right click ADSI Edit and click on Connect To.
4. Select “Well known Naming Context” and from the drop down menu select “Schema” as the following snapshot:
5. Browse to CN=ms-Exch-Smtp-Tls-Certificate, open the properties and scroll down to rangeUpper as the following snapshot
6. Click Edit and enter the new value 1024, as the following snapshot:
7. Enforce the replication by running repadmin /syncall from the command prompt.
8. Verify that the rangeupper limit has been increased by running the following command:
dsquery * CN=ms-Exch-Smtp-TLS-Certificate,CN=Schema,CN=Configuration,DC=DOMAIN_NAME,DC=com -scope base -attr rangeUpper
It should be noted that if you don't want to change the schema you can simply re-word your subject field to get you under the 256 characters between the issuer and subject. This requires requesting a new certificate though.
@Kyle : that's exactly what I said "The first option now that we issue a new certificate with shorter name in the subject field as we don’t have control over the Issuer field."
Great article! This work for me!
lets cif workS T hank Sthough
Great post - this applies to anyone who happens to use a Comodo TLS certificate because that CA is issuing all of their certificates with strings that are longer than 256 characters.
The upper limit has been increased by Microsoft to 1024 in Exchange 2013 CU6.