Cloud Code Signing Integration with GitLab CI

This is a tutorial on how to do automated code signing on GitLab CI using eSigner CodeSignTool. 

CodeSignTool is a secure command line utility that forms part of eSigner: our cloud code signing environment that benefits software publishers and developers with its capacity to safely and efficiently conduct enterprise code signing in a non-complicated manner.  The sample workflow below shows a .NET DLL code being signed on GitLab CI with eSigner.

SSL.com’s EV Code Signing certificates help protect your code from unauthorized tampering and compromise with the highest level of validation, and are available for as little as $249 per year. You can also use your EV Code Signing certificate at scale in the cloud using eSigner.

ORDER NOW

Environment Variables

  • USERNAME: SSL.com account username. (Required)
  • PASSWORD: SSL.com account password (Required)
  • CREDENTIAL_ID: Credential ID for signing certificate. If credential_id is omitted and the user has only one eSigner code signing certificate, CodeSignTool will default to that. If the user has more than one code signing certificate, this parameter is mandatory. (Required)
  • TOTP_SECRET: OAuth TOTP Secret. You can access detailed information on https://www.ssl.com/how-to/automate-esigner-ev-code-signing (Required)
  • ENVIRONMENT_NAME : ‘TEST’ or ‘PROD’ Environment. (Required)

Inputs

  • input_file_path: Path of code object to be signed. (Required)
  • output_dir_path: Directory where signed code object(s) will be written. If output_path is omitted, the file specified in -file_path will be overwritten with the signed file.

.NET Code DLL Signing Example Workflow

Create a yml file

Group jobs into stages. All jobs in one stage must be completed before the next stage is executed.

stages:

  - build

  - sign
 

Define environment variables globally. Job level property overrides global variables.

  • Environment variables are used to make the samples more readable. In the screenshot above of the example workflow, the PROJECT_NAME, PROJECT_VERSION, and DOTNET_VERSION were optionally omitted. Signing can still proceed with these omissions.  
  • Under ENVIRONMENT_NAME, place “TEST” for test signing, and “PROD” for live signing.
variables:

  PROJECT_NAME: "HelloWorld"

  PROJECT_VERSION: "0.0.1"

  DOTNET_VERSION: "3.1"

  ENVIRONMENT_NAME: "PROD"
 

Define the Build Stage

Below is the definition of your job to build dll artifact

build-dotnet:

 

  1. Define what stage the job will run in.
  stage: build

 

  1. Place the full name of the image that should be used. It should contain the Registry part if needed.
 image: mcr.microsoft.com/dotnet/sdk:3.1-bullseye

 

  1. Define scripts that should run *before* the job. Can be set globally or per job.
before_script:

    - mkdir -p ${CI_PROJECT_DIR}/artifacts

    - mkdir -p ${CI_PROJECT_DIR}/packages

 

  1. Define Shell scripts executed by the Runner. Build DLL artifact
script:

    - dotnet build dotnet/${PROJECT_NAME}.csproj -c Release

    - cp dotnet/bin/Release/netcoreapp${DOTNET_VERSION}/${PROJECT_NAME}-${PROJECT_VERSION}.dll ${CI_PROJECT_DIR}/packages/${PROJECT_NAME}.dll

 

  1. Specify a list of files and directories that should be attached to the job if it succeeds.
  • The ‘expire_in‘ property allows the file to be deleted after a certain period of time. Its use is optional. This is why the screenshot of the example workflow above does not show this property.
artifacts:

    paths:

      - ${CI_PROJECT_DIR}/packages/HelloWorld.dll

    expire_in: 5 minutes
 

Define the Sign Stage

Below is the definition of your job to sign dll artifact

sign-dotnet-artifacts:

 

  1. Define what stage the job will run in.
  stage: sign

 

  1. Place the full name of the image that should be used. It should contain the Registry part if needed.
 image: docker:19.03.0

 

  1. Define services. This is similar to `image` property, but will link the specified services to the `image` container.
services:

    - docker:19.03.0-dind

 

  1. Define environment variables for specific jobs.
  • In the screenshot above, the sign command was defined directly in the sign script and not under environment variables. Both methods can sign correctly with TravisCI.
  variables:

    COMMAND: "sign"

 

  1. Define scripts that should run *before* the job. Can be set globally or per job.
  before_script:

    - mkdir -p ${CI_PROJECT_DIR}/artifacts

    - mkdir -p ${CI_PROJECT_DIR}/packages

 

  1. Place Shell scripts executed by the Runner. Sign .NET dll artifact with CodeSignTool Docker Image
script:

    - docker pull ghcr.io/sslcom/codesigner:latest

    - docker run -i --rm --dns 8.8.8.8 --network host --volume ${CI_PROJECT_DIR}/packages:/codesign/examples --volume ${CI_PROJECT_DIR}/artifacts:/codesign/output -e USERNAME=${USERNAME} -e PASSWORD=${PASSWORD} -e CREDENTIAL_ID=${CREDENTIAL_ID} -e TOTP_SECRET=${TOTP_SECRET} -e ENVIRONMENT_NAME=${ENVIRONMENT_NAME} ghcr.io/sslcom/codesigner:latest ${COMMAND} -input_file_path=/codesign/examples/${PROJECT_NAME}.dll -output_dir_path=/codesign/output

 

  1. Write the script that can be used to specify a list of files and directories that should be attached to the job if it succeeds.
artifacts:

    paths:

      - ${CI_PROJECT_DIR}/artifacts/${PROJECT_NAME}.dll

    expire_in: 1 days

 

  1. Specify a list of job names from earlier stages from which artifacts should be loaded.
dependencies:

    - build-dotnet

SSL.com’s EV Code Signing certificates help protect your code from unauthorized tampering and compromise with the highest level of validation, and are available for as little as $249 per year. You can also use your EV Code Signing certificate at scale in the cloud using eSigner.

ORDER NOW

Initiate the Build Stage

Create a repository

Refer to the Command line instructions on Gitlab as seen in the screenshot below

Push your folder

Do this by clicking Terminal on the menu, followed by New Terminal.

Type the push script on your Terminal  to push the project 

Click the Build button

After triggering the pipeline, proceed to build

Check if the build is successful  

Initiate the Sign Stage

Proceed to sign the artifact

Confirm if the code signing is successful

You can now download the signed file

You can refer to the SSL.com Github repository which contains the source codes of the docker image and describes how to use it: https://github.com/SSLcom/ci-images 

Sample Gitlab CI Pipeline

Check out the sample Gitlab CI pipeline we have created on github.com/SSLcom/codesigner-gitlabci-sample

Other CI/CD Remote Signing Integration Guides

Need Custom Solutions? 

With our expert knowledge and five-star support staff, we’re ready and willing to work with you on custom solutions or enterprise-level high-volume signing discounts. Fill out the form below and we’ll be in touch.

Subscribe To SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com

Stay Informed and Secure

SSL.com is a global leader in cybersecurity, PKI and digital certificates. Sign up to receive the latest industry news, tips, and product announcements from SSL.com.

We’d love your feedback

Take our survey and let us know your thoughts on your recent purchase.