19. Enabling HTTPS

By default, the REST endpoints use plain HTTP as a transport. You can switch to HTTPS easily, by adding a certificate to your configuration in e.g. skipper.yml.


You can reference the Yaml file using the following parameter: --spring.config.location=skipper.yml

  port: 8443                                         1
    key-alias: yourKeyAlias                          2
    key-store: path/to/keystore                      3
    key-store-password: yourKeyStorePassword         4
    key-password: yourKeyPassword                    5
    trust-store: path/to/trust-store                 6
    trust-store-password: yourTrustStorePassword     7


As the default port is 7577, you may choose to change the port to a more common HTTPs-typical port.


The alias (or name) under which the key is stored in the keystore.


The path to the keystore file. Classpath resources may also be specified, by using the classpath prefix: classpath:path/to/keystore


The password of the keystore.


The password of the key.


The path to the truststore file. Classpath resources may also be specified, by using the classpath prefix: classpath:path/to/trust-store


The password of the trust store.


If HTTPS is enabled, it will completely replace HTTP as the protocol over which the REST endpoints interact. Plain HTTP requests will fail - therefore, make sure that you configure the Skipper Shell accordingly.

19.1 Using Self-Signed Certificates

For testing purposes or during development it might be convenient to create self-signed certificates. To get started, execute the following command to create a certificate:

$ keytool -genkey -alias skipper -keyalg RSA -keystore skipper.keystore \
          -validity 3650 -storetype JKS \
          -dname "CN=localhost, OU=Spring, O=Pivotal, L=Holualoa, ST=HI, C=US"  1
          -keypass skipper -storepass skipper


CN is the only important parameter here. It should match the domain you are trying to access, e.g. localhost.

Then add the following to your skipper.yml file:

  port: 8443
    enabled: true
    key-alias: skipper
    key-store: "/your/path/to/skipper.keystore"
    key-store-type: jks
    key-store-password: skipper
    key-password: skipper

This is all that’s needed for the Skipper Server. Once you start the server, you should be able to access it via https://localhost:8443/. As this is a self-signed certificate, you will hit a warning in your browser, that you need to ignore.

19.2 Self-Signed Certificates and the Shell

By default self-signed certificates are an issue for the Shell and additional steps are necessary to make the Shell work with self-signed certificates. Two options are available:

  1. Add the self-signed certificate to the JVM truststore
  2. Skip certificate validation

Add the self-signed certificate to the JVM truststore

In order to use the JVM truststore option, we need to export the previously created certificate from the keystore:

$ keytool -export -alias skipper -keystore skipper.keystore -file skipper_cert -storepass skipper

Next, we need to create a truststore which the Shell will use:

$ keytool -importcert -keystore skipper.truststore -alias skipper -storepass skipper -file skipper_cert -noprompt

Now, you are ready to launch the Skipper Shell using the following JVM arguments:

$ java -Djavax.net.ssl.trustStorePassword=skipper \
       -Djavax.net.ssl.trustStore=/path/to/skipper.truststore \
       -Djavax.net.ssl.trustStoreType=jks \
       -jar spring-cloud-skipper-shell-1.0.0.BUILD-SNAPSHOT.jar

In case you run into trouble establishing a connection via SSL, you can enable additional logging by using and setting the javax.net.debug JVM argument to ssl.

Don’t forget to target the Skipper Server with:

skipper:>skipper config --uri https://localhost:8443/api

Skip Certificate Validation

Alternatively, you can also bypass the certification validation by providing the optional command-line parameter --spring.cloud.skipper.client.skip-ssl-validation=true.

Using this command-line parameter, the shell will accept any (self-signed) SSL certificate.


If possible you should avoid using this option. Disabling the trust manager defeats the purpose of SSL and makes you vulnerable to man-in-the-middle attacks.