The Digicert service is available for JARs and Windows executables and code signing for both test and production builds.
Production signing costs the ASF real money. Only use the production signing service once the release process works using test signing.
Once you have access to the signing service, you receive a personal certificate from Symantec. You need this to access the code signing GUI.
The production system is available at: https://securesigning.pki.digicert.com/csportal/. When you submit a signing request, you can choose to perform a test or a production signing.
To add users to your PMC's signing organization
To create a new signing set, you need to have a set of files to sign. The steps below uses the Apache Tomcat Windows installer as an example.
You can then download the signed files.
You need to specify the name of the signing service to use. The names are shown in the table below:
|Artifact type||Text signing service||Production signing service|
|Windows binary (
||Microsoft TEST Signing||Microsoft Windows Signing|
|Java Signing (
||Java TEST Signing||Java Signing|
Both SHA1 and SHA256 versions of the Java Signing service are available. Apache recommends using the SHA256 service. However, if you are re-signing JARs that have already been signed, make sure to use the same hash algorithm as the original signature to avoid breaking the original signature.
Java signing is not intended to replace the current requirement for releases to be OpenPGP signed. Neither is it intended to replace the process of providing OpenPGP signatures for JARs uploaded to Maven Central. It is intended for those use cases that require individual JAR files to be signed using the standard Java JAR signing process where the signature is contained within the JAR. Such use cases include Java Web Start, Eclipse plug-ins, etc.
A signing event is the process of signing one or more files. Whether you use the web GUI or the SOAP API, the files must have unique names. You may have to rename files prior to signing and change the file names back afterwards. Reverting the name does not affect the signature of the file.
The signing service is particular about file extensions. If you do rename a file, make sure that it retains the correct file extension.
You can revert each signing event individually.
You can request production or test signing on both the production and test systems. Only a production signing event on the production system costs the ASF a code signing credit. We recommend that projects start testing with production signing on the test environment and get their process working there before moving to the production environment.
The Apache Tomcat project has written an Ant task that uses the SOAP interface (see below) to sign release artifacts as part of the build process. To use the SOAP interface, your PMC account needs to be enabled for API access. Open an Infra Jira ticket against the code signing component to request this. Once this is approved you will receive your:
You need all three to access the API.
This Tomcat Ant task uses a fixed buffer of 16MB to store the zipped artifacts for signing. If your artifacts are larger than that, you need to use a larger buffer. Patches to switch to streaming the artifacts rather than buffering them are welcome.
A Maven plug-in to facilitate code signing is a work in progress.
The SOAP API documentation is under an NDA, and this link is only availabe to ASF members. Please do not share the documentation outside your PMC, and make sure those you share it with are aware of the NDA. If you need a copy of the API docs, request it via a PMC member who is also an ASF member. If that is not possible, request it from Infra.