This repo contains the source code for the core headless CA service. The service is "headless", which means that it has no web GUI for management and cert issuance and consequently provides no login support for admin login. The only option tha manage this CA service is by means of a CMC API and direct access to the CA repository. This CA service is intended to be used as a generic CA service that is managed through authorizes CMC clients (RA).
Such CA CMC client suitable for use with this CA service is available here: https://github.com/swedenconnect/ca-cmc-admin
The source code for this CA service builds a Spring Boot application that may be deployed as is, or may be built into a Docker image using any of the provided Dockerfile examples.
This document provides build, deployment and operational instructions. Example files used to illustrate service deployment are provided in the documentation/sample-config folder.
The CA service application may hold any number of Certification Authority (CA) services, referred to as "Instances".
Each CA instance has its own CA repository and its own revocation services.
This project holds two complementary tool:
| Tool | Descritpion |
|---|---|
| CA Repository migration tool | Tool to merge data from one type of repository (e.g. file based) to another type (e.g. Database based) |
Building source codes referred to here requires maven version 3.3 or higher.
The master branch of each repo holds the latest code under development. This is usually a SNAPSHOT version. For deployment, it is advisable to build a release version. Each release have a corresponding release branch. To build the source code, select the release branch of the latest release version before building the source code.
The application is built by executing the following command from the project folder containing the pom.xml file:
mvn clean install
Three sample Dockerfile files are provided:
| Dockerfile | Description |
|---|---|
| Dockerfile | Builds a docker image that exposes all relevant default ports |
| Dockerfile-debug | Builds a docker image that allows attachment of a remote debugger on port 8000 |
A docker image can be built using the following command:
docker build -f Dockerfile -t headless-ca .
Please refer to the Docker manual for instructions on how to build and/or modify these docker images.
Testing with SoftHSM
HSM support for this CA service is based on the Credential Support library: https://github.com/swedenconnect/credentials-support Scripts for building an extended docker image with support for SoftHSM with imported and deployed keys are available here: https://github.com/swedenconnect/credentials-support/tree/main/hsm-support-scripts/soft-hsm-deployment
The following environment variables are essential to the CA application:
| Environment variable | Description |
|---|---|
SPRING_CONFIG_ADDITIONAL_LOCATION |
Specifies the absolute path location of the configuration data folder. This folder must specify a location that is available to the CA application and the CA application must have write access to this folder and all its sub-folders. The absolute path specified by this variable must end with a delimiter ("/") so that ${SPRING_CONFIG_ADDITIONAL_LOCATION}child specifies the absolute path of the child folder. (Note: this is a rule set by Spring Boot). |
SPRING_PROFILES_ACTIVE |
Specifies an optional application profiles used by the CA service. This variable should be set to the value "nodb" if no database implementation of the CA repository is used (Se section on CA repository options). |
TZ |
Specifies the timezone used by the application. This should be set to "Europe/Stockholm" |
The documentation/sample-config folder contains sample configuration data. A corresponding folder must be available to the CA application at the location specified by SPRING_CONFIG_ADDITIONAL_LOCATION.
The configuration folder holds the following files and folders:
| Resource | Description |
|---|---|
cfg |
Holds optional configuration data files applicable to the CA application such as logotype image files |
cmc |
Holds optional configuration data files supporting the CMC API of the service as specified by application.properties values. |
instances |
holds configuration and data files related to all configured CA instances. |
application.properties |
Main configuration file |
The instances folder includes one folder for each instance of the CA service. Each folder has the name equal to the id of the instance defined in the main configuration file application.properties. In the sample configuration there are 2 instances named rot01 and ca01, where rot01 is a root CA service and the ca01 instance is a CA used to issue end entity certificates.
Each instance folder has 3 child folders as follows:
| Folder | Description |
|---|---|
certs |
This folder is used to store certificates that are used to represent this CA instance. |
keys |
This folder contains any necessary key files used to load the private/public key pair of this CA instance. |
repository |
This folder contains CA repository files for issued certificates as well as certificate revocation lists (CRL). |
The certs folder is typically populated by the following files on instance initialization:
| File | Description |
|---|---|
ca-chain.pem |
This file holds the chain of certificates used by the CA to represent a path to a trusted root certificate. This file is initially created containing a single certificate, being the self issued CA certificate stored in the ca-self-signed.crt file. This file may be modified manually by the administrator if this CA is certified by another CA in order to create a path to a trusted root. If this file is modified, then all certificates including the trusted root certificate must be included. The certificates should be stored in the order from the CA certificate first and the root certificate last. All certificate must be stored in its PEM format. |
ca-self-signed.crt |
This file holds the self signed CA certificate created for this CA instance at initialization. |
ocsp.crt |
This certificate appears if, and only if, the CA is configured include an OCSP responder and a separate key pair is provided for the OSCP responder. The OCSP responder certificate can be re-issued by deleting this certificate and restarting the service. The OSCP responder can be re-keyed by replacing the OCSP responder key pair and deleting this certificate and restarting the service. |
The keys folder is used to store files holding key pair data for the CA instance. The files stored here are different depending on the key type specified in the configuration data as follows:
| Key type | Content in keys folder |
|---|---|
jks |
Stores Java key store files for the CA and for the OCSP responder (if applicatble). File names must end with ca.jks for CA keys and ocsp.jks for OCSP keys. |
pkcs12 |
Stores PKCS#12 files for the CA and for the OCSP responder (if applicatble). File names must end with ca.p12 for CA keys and ocsp.p12 for OCSP keys. |
pkcs11 |
Applicable if the private key is stored in an external HSM device. This folder must contain a certificate file for the public key of the corresponding private key in the HSM. File names must end with ca.crt for CA keys and ocsp.crt for OCSP keys. |
pem |
Stores private keys and public key certificates in separate files. File names must end with ca.key for CA keys, ca.crt for CA public key certificates, ocsp.key for OCSP keys and ocsp.crt for OCSP public key certificates. |
create |
empty |
none |
empty |
Note that create option is only for test and causes the service to generate new keys at every startup. The option none means no key and this option is selected for OCSP responders that will issue OCSP responses using the CA key instead of a separate key for a separate OCSP responder entity.
The repository folder is internally used by the CA instance to store data related to the CA repository and issued revocation data.
Configuration data for the service an all CA instances are specified in the application.properties file. Properties settings are divided into sub categories as follows:
Process logging levels are set accoreding to Spring Boot conventions. Two logging levels are preset:
| Logging level property | Description |
|---|---|
| logging.level.se.swedenconnect.ca | Setting logging level for the CA service. |
| logging.level.se.swedenconnect.opensaml.pkcs11 | Setting logging level for processes related to HSM usage |
Logging levels can be set to the values: TRACE, DEBUG, INFO, WARN or ERROR
All regular general Spring Boot application.properties settings apply to this service. In addition to these properties, this service define a number of its own general service settings. The following properties should be set to appropriate values:
| Propety | Value |
|---|---|
| server.port | The main server port. Default 8080 |
| ca-service.config.control-port | The alternative internal server port. Default 8006 |
| ca-service.config.base-url | The base URL of the CA service (Only protocol and host name such as: https://service.example.com), not including any path information. |
| ca-service.config.verbose-cert-print | Determines the level of detail in presentation of certificate information. Default set to false. Setting this to true will for example print the content of signature values and key parameters. |
| ca-service.policy.admin.enabled-ui-ports | The ports that are allowed to expose service front page. See details below. |
| ca-service.config.logo | The path to the logo of the service. Typically set to ${ca-service.config.data-directory}cfg/logo.svg |
| ca-service.config.icon | The path to the icon of the service. Typically set to ${ca-service.config.data-directory}cfg/icon.svg |
Note: The ca-service.policy.admin.enabled-ui-ports property includes a list of allowed ports for the front page. A typical setting is: ${ca-service.config.control-port} to allow the front page to be shown on the local network but not via the open internet.
Certified key constraints
These settings define the allowed public key types and minimum key length requirements for this CA to allow certification of a presented public key in a certification request.
| Propety | Value |
|---|---|
| ca-service.policy.rsa-keys-allowed | Set to true to allow RSA public keys |
| ca-service.policy.rsa-min-key-len | Minimum RSA key length. Default 3072 |
| ca-service.policy.ec-keys-allowed | Set to true to allow Elliptic Curve (EC) public keys |
| ca-service.policy.ec-min-key-len | Minimum EC key length. Default 256 |
The Spring boot application may provide its services over encrypted TLS as alternative to the main service port. This communication is allways offered on port 8443. TLS is configured using the following standard Spring Boot properties
| Propety | Value |
|---|---|
| server.ssl.key-store | Location of the TLS server key and certificate such as ${ca-service.config.data-directory}cfg/sslSnakeOil.p12 |
| server.ssl.key-store-type | Key store type, such as PKCS12 |
| server.ssl.key-store-password | Key store password |
| server.ssl.key-password | Key password |
| server.ssl.enabled | Set to true to enable TLS |
These settings are disabled by default
AJP is disabled by default. AJP protocol support can be enabled ans specified using the following property settings:
| Propety | Value |
|---|---|
| tomcat.ajp.enabled | Set to true to enable AJP support |
| tomcat.ajp.port | Set the AJP port. Typically 8009 |
| tomcat.ajp.secret | Sets an AJP secret to enahce security between the application and the web server. If this secret is absent, then AJP is provided with secure mode set to false and without AJP secret. This is not recommended for production environments. |
The CA service offers process logging for the purpose of monitoring the service and to debug problems. This log does not need to be maintained over time.
In addition to this the CA service provides an audit log with information on important events to support audit of the service. This log is intended to be archived to allow future audits.
The audit log can be directed to external syslog servers. For details on syslog configuration, see section 5.
PKCS#11 configuration is only applicable if the service is connected to a HSM key source. For more details on HSM configuration, see chapter 4.
The CA service may provide any number of CA instances where each instance have its own set of keys, CA identity, CA settings and revocation services.
A typical configuration is to create a CA service with 2 instances, where one instance is a root CA and the other is the CA used to issue certificates to access points.
For a more secure setup, the Root CA should be established as a separate service deployment, completely separated from the CA issuing end entity certificates.
The basic asset of a CA instance is its key sources. A CA may have one or two key sources:
- The CA key source used to sign certificates and CRL (Certificate revocation lists).
- An optional OCSP key source used if the OCSP responder is provided by a separate entity with its own issuing key.
If no OCSP key source is specified, then this instance will issue OCSP responses (if OCSP is enabled) using the CA key instead of using a separate OCSP key.
A key sources are set up using the following parameters :
| Key soruce parameter | Value |
|---|---|
| type | Specifies the type of key source. See section 2.2.1.2 for the different key source types |
| alias | The alias/name of the key. for jks and pkcs12 key sources this value is the key alias in the key store. for pkcs11 this is the id of the key in the HSM and for pem keys this parameter is ignored. |
| pass | Password/secret used to access the key. for pem keys this is the key decryption password if the key is encrypted. If the pem key is no encrypted, this paramter is ignored. |
The property name format for a ca key is:
ca-service.instance.conf.{instance-id}.ca.key-source.{parameter-name}
The property name format for an ocsp key is:
ca-service.instance.conf.{instance-id}.ocsp.key-source.{parameter-name}
Example of key source configuration for the CA instance named ca01 with ca and ocsp key:
ca-service.instance.conf.ca01.ca.key-source.type=pkcs11
ca-service.instance.conf.ca01.ca.key-source.alias=ca01-key
ca-service.instance.conf.ca01.ca.key-source.pass=1234
ca-service.instance.conf.ca01.ca.key-source.reloadable-keys=true
ca-service.instance.conf.ca01.ocsp.key-source.type=jks
ca-service.instance.conf.ca01.ocsp.key-source.alias=ocsp
ca-service.instance.conf.ca01.ocsp.key-source.pass=secret
Instance service configuration is provided as a default configuration profile followed by specific configuration parameters for each instance that differs from the default parmeter.
property parameter naming for instance service configuration follows the following structure:
ca-service.instance.conf.{instance-id}.{entity=ca/ocsp}.{parameter-name}
The instance-id for the default profile is "default"
The following parameters are available for the "ca" entity type:
| Parameter | Value |
|---|---|
| type | The type of CA instance. The available values are "ca" and "root". The value determines the certificate content profile for issued certificates. |
| description | A Short description of the instance CA service. |
| algorithm | URI identifier of the algorithm used to sign certificates and revocation data. E.g. http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| allow-v1 | True if this CA is allowed to issue X.509 V1 certificates. Note that certificates with extensions are always V3 certificates. Default false. |
| self-issued-valid-years | The number of years the autogenerated self issued certificate will be valid |
| validity.start-offset-sec | The number of seconds before the actual issue time, issued certificates will be valid from. This allows time skew between the issuing service and certificate verifiers. |
| validity.unit | The unit type for validity period settings of issued certificates. Unit alternatives are "M", "H", "D" or "Y" for Minute, Hour, Day or Year (case insensitive) |
| validity.amount | The amount of time units issued certificates will be valid |
| crl-validity.start-offset-sec | Same as validity.start-offset-sec, but for CRL validity period. |
| crl-validity.unit | same as validity.unit, but for CRL validity period. |
| crl-validity.amount | same as validity.amount, but for CRL validity period. |
| crl-max-duration-before-upgrade | Duration from last new CRL creation where a request for creating a new CRL will create a copy of the old CRL unless there is a change in the count of revoked certificates. (Default 60s). |
The following parameters are available for the "ocsp" entity type:
| Parameter | Value |
|---|---|
| enabled | A value of true enable OCSP responder for this CA instance |
| algorithm | URI identifier of the algorithm used to sign OCSP responses |
| validity.start-offset-sec | Same as validity.start-offset-sec, but for OCSP validity period. |
| validity.unit | Same as validity.unit, but for OCSP validity period. |
| validity.amount | Same as validity.amount, but for OCSP validity period. However a value of "0" means that the OCSP response will not have a "Next update" time set. This is the typical configuration when OCSP responses is issued directly based on the CA repository source (The information is allways fresh). |
THe following example illustrates typical default and instance service configuration for the instances named ca01 and rot01:
ca-service.instance.conf.default.ca.algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
ca-service.instance.conf.default.ca.allow-v1=false
ca-service.instance.conf.default.ca.self-issued-valid-years=10
ca-service.instance.conf.default.ca.validity.start-offset-sec=-20
ca-service.instance.conf.default.ca.validity.unit=Y
ca-service.instance.conf.default.ca.validity.amount=2
ca-service.instance.conf.default.ca.crl-validity.start-offset-sec=0
ca-service.instance.conf.default.ca.crl-validity.unit=H
ca-service.instance.conf.default.ca.crl-validity.amount=2
ca-service.instance.conf.default.ocsp.enabled=true
ca-service.instance.conf.default.ocsp.algorithm=${ca-service.instance.conf.default.ca.algorithm}
ca-service.instance.conf.default.ocsp.validity.start-offset-sec=-10
ca-service.instance.conf.default.ocsp.validity.unit=H
ca-service.instance.conf.default.ocsp.validity.amount=0
ca-service.instance.conf.rot01.enabled=true
ca-service.instance.conf.rot01.ca.type=root
ca-service.instance.conf.rot01.ca.description=Root CA service for certification of CA services
ca-service.instance.conf.rot01.ca.validity.amount=10
ca-service.instance.conf.rot01.ca.name.common-name=ROOT CA service
ca-service.instance.conf.rot01.ca.self-issued-valid-years=20
ca-service.instance.conf.rot01.ca.crl-validity.unit=D
ca-service.instance.conf.rot01.ca.crl-validity.amount=35
ca-service.instance.conf.rot01.ocsp.enabled=false
ca-service.instance.conf.ca01.enabled=true
ca-service.instance.conf.ca01.ca.type=ca
ca-service.instance.conf.ca01.ca.description=CA service for issuing end entity certificates
ca-service.instance.conf.ca01.ca.validity.amount=2
ca-service.instance.conf.ca01.ca.name.common-name=Common name for this CA
ca-service.instance.conf.ca01.ca.self-issued-valid-years=10
ca-service.instance.conf.ca01.ocsp.name.common-name=OCSP Responder
This CA service includes the alternatives to use file storage or database storage for the CA repository.
Use of database storage is the default option which requires application.properties to include appropriate settings for the database connection
for the repository. The option to use file based storage is mainly intended for test, but may be used in production environments where the operational
security advantages of a complete database is not required or desired. In order to use the file based CA repository it is necessary to opt-out of
database usage. This can be done by activating the Spring profile "nodb" (See section 2.1). Using this profile causes the application to use a file based
repository and causes the application to ignore any database settings below.
Database implementation use Spring Boot JPA (Jakarta Persistence API). This implementation allows a wide range of settings to optimize connection to any type of database. A useful guide is available here (A guide to JPA with Spring).
The dependencies of this project includes necessary dependencies for MySQL and PostgreSQL. To use any other DB service, relevant dependencies must be added to the project.
Multiple server deployment:
Multiple server deployment is supported when a database is used to share the CA repository data. In this case the database is used to ensure that certificate and revocation information is synchronized between the server instances.
This synchronization works out of the box and do not require any setup beyond ensuring that the database setup is complete with all necessary tables.
Database is configured using Spring Boot property settings for JPA and spring datasource properties as described in this section. The following general settings are allways relevant.
| Property | Description |
|---|---|
| spring.jpa.hibernate.ddl-auto | This property decides wether the appikcation should create or update the database on startup. The choices are: create, update, create-drop, validate, and none. create is used to create the database on first startup unless the database is created using a script or by other means. Once the database table is created, the service should allways use the none option. |
| spring.datasource.url | Specifies the url to the database. e.g: jdbc:mysql://10.1.1.2:3306/headless_ca |
| spring.datasource.username | The username of the db account accessing the database |
| spring.datasource.password | The password of the db account user |
These are the only options that are needed in order to connect to a MySQL database.
When connection to a PostgreSQL database, the following additional properties should be set:
| Property | Description |
|---|---|
spring.jpa.database=POSTGRESQL |
Setting database to PostgreSQL in JPA |
spring.datasource.platform=postgres |
Setting database to PostgreSQL in Spring datasource |
spring.jpa.properties.hibernate.jdbc.lob.non_contextual_creation=true |
This entry is put just to avoid a warning message in the logs when you start the spring-boot application. This bug is from hibernate which tries to retrieve some metadata from postgresql db and failed to find that and logs as a warning. |
The following property settings could be considered in addition to the settings above:
| Property | Description |
|---|---|
| spring.jpa.generate-ddl=true | Work as a master switch for the spring.jpa.hibernate.ddl-auto setting described above. If theis setting is set to false, then all autogenerate actions are disabled. |
| spring.jpa.show-sql=true | Setting this property to true sends SQL query messages to standard out. |
Here are some typical configuration examples:
MySQL
spring.jpa.hibernate.ddl-auto=none
spring.datasource.url=jdbc:mysql://10.1.1.2:3306/headless_ca
spring.datasource.username=cadbuser
spring.datasource.password=S3crEt
PostgreSQL
spring.jpa.database=POSTGRESQL
spring.datasource.platform=postgres
spring.datasource.url=jdbc:postgresql://localhost:5432/postgres
spring.datasource.username=postgres
spring.datasource.password=root
spring.jpa.show-sql=true
spring.jpa.generate-ddl=true
spring.jpa.hibernate.ddl-auto=none
spring.jpa.properties.hibernate.jdbc.lob.non_contextual_creation=true
The CA repository requires two tables named dbcertificate_record and crl_metadata. These tables can be created programmatically using spring.jpa.hibernate.ddl-auto=create
or spring.jpa.hibernate.ddl-auto=update.
For more control, it may be advisable to manually create the database using a SQL create statement. The precise syntax of such create statement may differ for different
databases. The following create statement can be used to create the necessary tables in MySQL:
CREATE TABLE `dbcertificate_record` (
`id` varchar(255) NOT NULL,
`certificate` blob NOT NULL,
`expiry_date` bigint DEFAULT NULL,
`instance` varchar(255) DEFAULT NULL,
`issue_date` bigint DEFAULT NULL,
`reason` int DEFAULT NULL,
`revocation_time` bigint DEFAULT NULL,
`revoked` bit(1) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
CREATE TABLE `crl_metadata` (
`instance` varchar(255) NOT NULL,
`crl_number` varchar(255) DEFAULT NULL,
`issue_time` bigint DEFAULT NULL,
`next_update` bigint DEFAULT NULL,
`rev_count` int DEFAULT NULL,
PRIMARY KEY (`instance`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
The following provides a sample docker start command to run the service as docker container.
The image name of this example is set to headless-ca. This name can however be set to any suitable tag name when building the docker image.
docker run -d --name headless-ca --restart=always \
-p 9070:8080 -p 9079:8009 -p 9073:8443 -p 9077:8000 -p 9076:8006 -p 9078:8008 \
-e "SPRING_CONFIG_ADDITIONAL_LOCATION=/opt/ca/" \
-e "SPRING_PROFILES_ACTIVE=nodb" \
-e "TZ=Europe/Stockholm" \
-v /etc/localtime:/etc/localtime:ro \
-v /opt/docker/headless-ca-hsm:/opt/ca \
headless-ca
A new CA instance is created using the following procedure:
- Create an instance data folder with the instance-id as the folder name, and then create a subfolder named "keys" inside the instance folder.
- Generate keys for the CA and its OCSP responder and store the applicable files in the "keys" folder.
- Update the application.properties file with appropriate property settings for the new instance.
- Restart the CA service. This will cause the service to initialize the new instance CA repository and to generate new self issued CA certificate and OCSP certificate in the "repository" and the "certs" folders.
If this CA instance is a root CA (is not signed by another CA higher in the trust path), then stop here. If this CA is a CA that should be signed by a root CA, then proceed as described in the next steps below. These instructions assume that the new instance created through step 1-4 is named "new-ca".
- Locate the self-issued CA certificate in the "certs" folder of "new-ca".
- Obtain a new CA certificate for this CA by the signing CA higher in the trust chain. This could be another CA provided by another instance of this CA service. In such case the self signed certificate in "ca-chain.pem" can be used to request a new CA certificate.
- Replace the content of the file "ca-chain.pem" in the instance "new-ca". Remove the existing self-signed certificate and place instead the following certificates in this order:
a. The new CA certificate issued for this service in step 6
b. The self issued certificate of the CA that signed che certificate in step 6. - Restart the CA service
Issuing and revoking certificates in the CA service provided by this application is exclusively done through the CMC API. Please refer to the documentation of the ca-cmc library for documentation of the CMC API. This library also provides code for implementing a compatible CMC client used to request and revoke certificates.
External PKCS#11 tokens, as well as softhsm PKCS#11 tokens can be configured through an external PKCS#11 configuration file using the following properties in application.properties value:
| Parameter | Value |
|---|---|
ca-service.pkcs11.external-config-locations |
Specifies an absolute file name (and path) to a PKCS#11 configuration file used to setup PKCS11 providers. |
Audit logs can be sent to Syslog by:
- Setting
application.propertiespropertyca-service.syslog.enabledto the value true - Configuring available syslog hosts in the configuration file
application.properties.
Note: If syslog is not enabled according to step 1 above, then the audit log will be available through the management port according to section 6, under the relative path "auditevents". (E.g http://localhost:8008/manage/auditevents).
Parameters are specified in the form: ca-service.syslog.config[index].{parameter} illustrated by the example below.
Sample syslog.properties file:
# Parameters:
# - host : Hostname or IP addresses
# - port : TCP or UDP port
# - protocol : udp, tcp or ssl
# - bsd : Using message format RFC_3164 when set to true. Using RFC_5424 (UDP) or RFC_5425
# : (TCP) when false
# - facility : The syslog facility identifier (0-23)
# - loglevel : The log level for logging (Default INFORMATIONAL) or set to either numerical or
# : label that is one of:
# : 0 - EMERGENCY, 1 - ALERT, 2 - CRITICAL, 3 - ERROR, 4 - WARNING, 5 - NOTICE,
# : 6 - INFORMATIONAL, 7 - DEBUG
# - clienthostname : Name of the sending client host. If absent, the client host is set to the value
# : of the environment variable "HOSTNAME".
# - clientapp : Name of the sending client application
ca-service.syslog.enabled=true
ca-service.syslog.config[0].host=10.1.1.101
ca-service.syslog.config[0].port=601
ca-service.syslog.config[0].protocol=tcp
ca-service.syslog.config[0].bsd=false
ca-service.syslog.config[0].facility=13
ca-service.syslog.config[0].clientapp=ca-service
ca-service.syslog.config[1].host=10.1.1.102
ca-service.syslog.config[1].port=514
ca-service.syslog.config[1].protocol=udp
ca-service.syslog.config[1].bsd=false
ca-service.syslog.config[1].facility=14
ca-service.syslog.config[1].clientapp=ca-service
The CA application can be monitored remotely through configurable url and port. Monitoring is provided using Spring boot actuator and is configured through settings in application.properties as follows.
| parameter | Value |
|---|---|
| management.server.base-path | The path to the monitoring service. Typically set to "/manage" |
| management.server.port | The tcp port at which the information is available |
| management.server.ssl.enabled | Set to true to enable SSL/TLS protection |
| management.endpoint.info.enabled | Enabling the "info" feed on /info if set to true |
| management.endpoint.health.enabled | Enabling the health feed on /health if set to true |
| management.endpoint.auditevents.enabled | Enabling the audit events feed on /auditevents if set to true |
| management.endpoints.web.exposure.include | Default "*" |
| management.endpoints.web.base-path | Default "/" |
| management.server.ssl.key-store= | Key store path |
| management.server.ssl.key-store-password | Key store password |
| management.server.ssl.key-password | Key password |
| management.server.ssl.key-store-type | Keystore type (e.g. "PKCS12") |
| management.server.ssl.key-alias | Keystore alias |
URL:s provide information about the service as follows:
http[s]://{service-IP-address}:{management.port}{management.context-path}{resource-name}
A typical URL for the "info" resource is:
The following resources are available:
| resource-name | Description |
|---|---|
| health | Service health indication |
| info | Information about the service |
| auditevents | Audit log (If no syslog server is assigned) |
Example: "health"
{"status":"UP"}
Example: "info"
{
"build": {
"artifact": "ca-service-base",
"name": "ca-service-base",
"time": "2021-03-28T19:13:31.355Z",
"version": "1.0.0",
"group": "se.swedenconnect.ca"
},
"CA-service-information": {
"serviceUrl": "https://service.example.com/ca",
"contextPath": "/ca",
"servicePort": 8080,
"adminPort": 8006,
"managePort": 8008,
"ajpConfig": {
"port": 8009,
"secret": true
},
"caInstances": [
{
"id": "ca01",
"enabled": true,
"serviceType": "ca",
"keySourceType": "pkcs11",
"keyInfo": {
"keyType": "RSA",
"keyLength": 3072
},
"algorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
"dn": "C=SE,O=Myndigheten för digital förvaltning,OU=SDK,organizationIdentifier=202100-6883,CN=Accesspunkt CA-SDK-TEST",
"caPath": [
"C=SE,O=Org,OU=Org Unit,organizationIdentifier=202100-6883,CN=CommonName",
"C=SE,O=Org,OU=Org Unit,organizationIdentifier=202100-6883,CN=Rot CA-TEST"
],
"crlDistributionPoints": ["https://service.example.com/ca/crl/ca01.crl"],
"oscpEnabled": true,
"ocspInfo": {
"ocspServiceUrl": "https://service.example.com/ca/ocsp/ca01",
"separateEntity": true,
"ocspEntity": {
"dn": "C=SE,O=Org,OU=Org Unit,organizationIdentifier=202100-6883,CN=CommonName OCSP Responder",
"keySourceType": "pkcs11",
"keyInfo": {
"keyType": "RSA",
"keyLength": 3072
},
"algorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
}
}
},
{
"id": "rot01",
"enabled": true,
"serviceType": "root",
"keySourceType": "pkcs11",
"keyInfo": {
"keyType": "RSA",
"keyLength": 3072
},
"algorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
"dn": "C=SE,O=Org,OU=Org Unit,organizationIdentifier=202100-6883,CN=Rot CA-TEST",
"caPath": ["C=SE,O=Org,OU=Org Unit,organizationIdentifier=202100-6883,CN=Rot CA-TEST"],
"crlDistributionPoints": ["https://service.example.com/ca/crl/rot01.crl"],
"oscpEnabled": false,
"ocspInfo": null
}
]
}
}
Copyright © 2022, Myndigheten för digital förvaltning - Swedish Agency for Digital Government (DIGG). Licensed under version 2.0 of the Apache License.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent