CodeSign FAQ

Is a Code Signing Certificate tied to my domain name?
No, a Code Signing Certificate is tied to your Organization Name only. The Common Name you are prompted for is required by our system in order for the request to be accepted, but we will replace it in our system with the Organization Name you have entered in your CSR so that the correct details will be displayed when the signature on the code is viewed.

Are thawte certificates compatible with Apple code signing technologies?
Currently , no. Only the JDK shipped for Mac OS X will support CA signed certificates. All Apple SDK's intended for OS's prior to OS X do not support CA signed Certificates.

How long can I use a Code Signing Certificate for?
Code Signing Certificates are valid for 1 or 2 years depending on which life cycle you choose when you purchase the certificate.Please note: For Microsoft Authenticode, you should also timestamp your signed code to avoid your code expiring when your certificate expires.

Is timestamped code valid after a Code Signing Certificate expires?
Microsoft Authenticode allows you to timestamp your signed code. Timestamping ensures that code will not expire when the certificate expires because the browser validates the timestamp. The timestamping service is provided courtesy of VeriSign. If you use the timestamping service when signing code, a hash of your code is sent to VeriSign’s server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.

Please specify VeriSign’s timestamp server url when you sign a CAB/EXE/DLL/OCX or Office project (Macro) file. The timestamp server validates the date and the time that the file was signed therefore the certificate can expire but the signature will be valid for as long as the file is in production. A new certificate is only necessary if you want to sign additional code or re-sign code that has been modified.

If you do not use the timestamping option during the signing, you must re-sign your code and re-send it out to your customers.

To verify if your file has been timestamped, use the chktrust.exe utility included with the Authenticode SDK tools. The date and time will be displayed when the file has been timestamped. "Unknown date and time" will appear when the file has NOT been timestamped. Please sign and timestamp your code using the instructions provided in the following Solution: SO2706

Unfortunately, there is no timestamping for Netscape Object Signing and JavaSoft Certificates. Therefore you need to re-sign your code with a new certificate after the old certificate expires.

Is there a limit to the number of applications that are allowed to be signed with a Code Signing Certificate?
No, thawte does not limit you to any specific number. You can sign as many applications with a Code Signing Certificate as you wish, provided that the applications are used for and distributed by the organization that owns the certificate.

Will I be prompted with the certificate again if I sign the same code with a different Certificate?
Yes, if you sign the same code with a new certificate, you will be prompted to accept the new certificate when you try to download the same code because the browser does not have any record of the new certificate.

When you accept the new certificate, you may select the option “Always trust content from My Company Ltd” so that you will not be prompted again, or you may leave the option unchecked in which case it will prompt you the next time you download the signed code.

When viewing a Code Signing Certificate in both IE and Netscape, I get a warning message?
You may receive one of the following errors when viewing your developer certificate in your browser's personal certificate store.
Internet Explorer: "Certificate not trusted for all intended purposes."
Netscape Navigator: "Not an email certificate."

These warning messages are caused by a bug in IE5.x which does not recognize the code signing certificate extensions thawte uses. Netscape expects all certificates in its certificate store to be for 'email', and displays this error when the certificate is for 'code-signing'. These errors do not affect the signing, use, or trust of the signed code, and are not displayed when your clients view your certificate.

Why is User is not prompted for certificate after downloading application?
The correct setting under the 'Security' option in Internet Explorer is not enabled. In order to receive the Certificate pop-up when the file is downloaded, you will need to enable a setting in Internet Explorer.

The setting can be found under:
Tools > Internet Options > Advanced > Scroll to the bottom of the list to 'Security'
Make sure that the following option is checked: "Check for signatures on downloaded programs"

How do I change the friendly name of my Microsoft Authenticode Certificate?
The thawte system does not assign a unique nickname to the certificate. Instead, a rather long thread of numbers is assigned to the certificate, and this can make code signing very cumbersome if you need to convert the Certificate for Netscape or Java signing.

Edit the value assigned to the certificate by following these steps:
In Internet Explorer, Tools > Internet Options > Content > Certificates
Click on View > Details > Edit Properties
Select your code-signing certificate
Select a friendly name for your certificate
Click "OK" and close window
You should now be able to view the nickname you just assigned to the certificate when you view it in Netscape or Internet Explorer.

Which browsers are supported by thawte Code Signing Certificates?
Platforms are not a good indicator of whether or not thawte certificates will be supported, as you can have various browser versions installed on a particular platform.

What we can tell you is that all versions of Microsoft Internet Explorer from 4.x up and Netscape 4.x up support thawte by default, 3.x versions of either browser need to be updated with the new thawte root Certificate.

Our Code Signing Certificates are signed with the thawte Code Signing CA Intermediate Certificate which is chained off the thawte Premium Server CA Root Certificate.

Which Sun JRE Plugins support thawte Code Signing Certificates?
thawte roots were shipped with JRE versions from 1.3.0_02 to the present JRE 1.5.0, therefore the roots are present in the cacerts keystore of every version from 1.3.0_02 to 1.5.0.

Are thawte Code Signing Certificates chained?
Yes, the thawte Code Signing Certificates are chained. The Code Signing Certificates are signed by the thawte Code Signing CA Intermediate Certificate which is chained to the thawte Premium Server CA Root certificate.

Developer Code-Signing Technology
Whenever an application attempts to access your system, it has the potential to do anything, be it expected, or unexpected. To safeguard users, any code seeking additional privileges must be signed. The certificate displayed, identifies the developer or organization deploying that code. The signature also prevents the code being 'tampered' with, and redeployed.

Getting a Developer Code-Signing Certificate
The required files are created by your browser during the enrollment process (except in the case of a JavaSoft Certificate) and our verification team then sets about verifying the details contained in the certificate request submitted to us once the enrolment has been completed. As soon as the details have been verified completely you are issued with a thawte Code Signing certificate which is tied to your Organisation.

thawte Developer Support
thawte is a trusted certificate provider. We do not make or support any software. We are more than happy to help wherever certificates are used, however, in the case of software specific issues, we may not always be able to help. The best people to contact will always be your software vendor.