Cloud Code Signing Integration with GitLab CI

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

2. 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

3. 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

4. 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

5. 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

2. Place the full name of the image that should be used. It should contain the Registry part if needed.

 image: docker:19.03.0

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

services:

    - docker:19.03.0-dind

4. 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"

5. 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

6. 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

7. 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

8. Specify a list of job names from earlier stages from which artifacts should be loaded.

dependencies:

    - build-dotnet

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

Sample Gitlab CI Pipeline

Other CI/CD Remote Signing Integration Guides

• Cloud Code Signing Integration with CircleCI
• Cloud Code Signing Integration with GitHub Actions
• Cloud Code Signing Integration with Jenkins CI
• Cloud Code Signing Integration with Travis CI
• Cloud Code Signing Integration with Azure DevOps
• Cloud Code Signing Integration with BitBucket
• Cloud Code Signing Automation with CI/CD Services

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.