Skip to content

Setup local development with .NET

Note

The following section is only when developing with dotnet and the Docker environment, it is not required for running the environment.

If you haven't already, please follow the getting started guide here.

To import the certificate for localhost development with dotnet the localhost certificate must be trusted by dotnet. This can be done using the following

dotnet dev-certs https --import <path-to-localhost.pfx> --clean --password default-password
  1. Open the Keychain Access app
  2. Go to the Certificate tab
  3. Mark them all as trusted for the localhost certificate
  4. Open the terminal and navigate to ./certificates
  5. Execute the following command

    1
    2
    3
        security import localhost.pfx \\       
        -k ${HOME}/Library/Keychains/login.keychain-db \\
        -t cert -f pkcs12 -P default-password -A
    

To check if the certificate has been installed correctly use the following command:

dotnet dev-certs https --check --trust

It should show something similar to:

A trusted certificate was found: <certificate-finger-print> - CN=localhost - Valid from 2023-05-10 10:02:55Z to 2028-05-08 10:02:55Z - IsHttpsDevelopmentCertificate: true - IsExportable: true

Making the Bizzkit Platform trust your endpoints

In some cases, the Bizzkit Platform will need to initiate an HTTPS connection to one of the applications in your development environment. When this is the case the container running the Bizzkit application must trust your application's SSL certificate.

This can be done in various ways:

  • Running your application on localhost reusing the certificate generated in the step above.
  • Using the Bizzkit tooling to generate additional certificates to be used by your application.
  • Mounting the Certificate authority file used to sign your certificate into the Bizzkit containers.
  • Using a valid and signed production certificate.

Using the Bizzkit tooling

If you opt for generating an additional certificate it can be done by mounting the config-file into the docker container from above e.g.

    docker run -it --rm -v .\certificates:/certs -v .\folder-with-cert-configs:/certconfigs crbizzkitpartner.azurecr.io/bizzkit/cert-generator:<bizzkit_product_version>
    docker run -it --rm -v ./certificates:/certs -v ./folder-with-cert-configs:/certconfigs crbizzkitpartner.azurecr.io/bizzkit/cert-generator:<bizzkit_product_version>

In this example, the folder-with-cert-configs is a folder containing OpenSSL config-files for any additional certificates that should be generated. As an example a certificate called mycustomer.config could look like this:

[req]
default_bits = 2048
distinguished_name = dn
req_extensions = aspnet
prompt = no

[dn]
CN=mycustomer.hdk

[aspnet]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, serverAuth
subjectAltName = DNS:*.mycustomer.hdk, DNS:mycustomer.hdk

This will generate a folder ./certificates/mycustomer containing the necessary certificate files including a .pfx-file that can be imported into the IIS.

Using the same "default-password" as mentioned above.

Mounting an additional Certificate authority

When using your own implementation of the reverse API that is hosted on a specific domain the Bizzkit applications need to trust the authority of the SSL certificate used, to do that you can mount the CA file to the following containers:

  1. pim-website
  2. pim-api
  3. pim-jobrunner
  4. pim-notificationhub
  5. dam-website
  6. dam-api
  7. dam-jobrunner
  8. cms-website
  9. cms-api

These containers can be found in docker-compose.app.yaml file and the way to mount the CA certificate is by adding a line under volumes

    - <path-to-ca-certificate>:/etc/ssl/certs/<certificate-name>.pem:ro