SSL certificates help secure encrypted communications between different services and servers. If a certificate cannot be verified by the Root Certificate Authority (CA) certificates, then this may indicate an attack. A second possibility for failed certificate verification could be a self-signed certificate (such as that of a second CES instance).
In such cases, tools such as
curl refuse to work because a safely encrypted communication to the desired services is not possible. There are often several possible solutions to this problem.
One of these approaches is to disable SSL certificate verification altogether. This approach has the strong disadvantage that often no certificates are checked at all. Malicious attacks would thus no longer be detectable.
A second solution approach is to recognize the affected certificates as secure. The services and tools can then secure their regular communications so that attacks from outside can be sensibly detected.
This document describes the second approach.
Inside the dogus, for the regular execution of Jenkins, there is the possibility to add additional certificates from the
There are some conditions to successfully find the certificates and apply them to the dogu.
- the certificates must be in PEM format.
the certificates must be present in
- The key name (also called alias) is used for addressing and dogu-internal storage and should not contain any spaces.
- It would make sense to use the FQDN of the service (e.g.
service.example.com), so that a certificate can be removed more easily later.
- A key can have more than one certificate for a service. Certificates in PEM format have textual markers that can be used to separate the certificates again.
the key name under which the certificate was stored must be stored in
- Certificates of different services must be separated with a single space character
Example configuration in
config/ └─ _global/ └─ certificate/ └─ additional/ ├─ toc -> "example.com localserver2 server3" ├─ example.com -> "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----" ├─ localserver2 -> "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----" └─ server3 -> "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
After a successful import, the certificates will be in these locations:
|name||file path||stored certificates|
|CA certificate collection||
||Both the standard CA certificates of the operating system from
||Both the operating system's default CA certificates from
|Subversion single certificates||
||additional certificates; if there are several certificates per alias, there will be several files which differ in the counter suffix|