Skip to Content
Author's profile photo Brenton OCallaghan

Replace all HTTPS certificates on a new SMP 3.0 installation

It still surprises me how many SMP/SUP implementations I work on where the replacement of the server SSL certificates is left to the last minute when in fact it only takes about 20 mins to complete as part of the install process. I am a firm believer that we should aim to be secure by default and I encourage everybody to do the same.

By default the install of SMP comes with a number of self-signed and untrusted certificates which can be annoying both from an admin perspective, as browsers will complain, but also annoying from an app perspective as devices generally don’t like insecure communications. So we need to replace these certs.

First lets start with a list of the HTTPS listening ports that we will need to address:

SMP 3.0

There are four main ports for SMP itself of which three use SSL. I of course am referencing the default port numbers here so you may need to adjust to fit any non-standard installation:

8081 – this is the HTTPS client connector for secure client communications

8082 – this is the Mutual SSL authenticator for secure certificate authenticated communications

8083 – this is the administration port on which you can find the admin console and uses SSL

In this case the replacement of the default certificate is pretty easy. With every installation in the SMP_HOME\Server\configuration folder there is a file called smp_keystore.jks. The first thing you ALWAYS do when manipulating the keystone is make a backup and that is as simple as copying the file. So do that first.

Next let’s list the contents – using the keytool command which is a standard command delivered as part of a JRE (java runtime environment) installation. So go to your command prompt, and navigate to the above location. Run the following command:


keytool -list -keystore smp_keystore.jks


Once you execute, one of two things will happen – you may get an error with the command keytool not found in which case the JRE is missing from your path. I won’t cover how to fix that here but it is widely documented on google if you need it. What should happen is that it prompts you for your keystore password which is the same as the one you provided during the SMP setup. Other default passwords from years gone by on SMP include changeit, changeit2 and s3pAdmin.

Once you enter your password you will be shown a list of the existing certificates in your keystone. In the list you should see an entry with the alias smp_crt which is the one we will be replacing. First I usually delete the existing cert that I will be replacing using the command:


keytool -delete  -alias smp_crt -keystore smp_keystore.jks


Once executed you will again be prompted for your password for the keystore. You may also be prompted for the password for the key you are deleting which is the same as the keystore.

Now we have to replace the cert we just deleted. For me, I have been provided a certificate and private key pair in a PKCS12 format or pfx file. You can generate a private key on the sever and get this signed by your CA but I find it easier to simply import the whole cert in one go. One point on your cert – you need to make sure the password for your pfx file matches the password on the SMP keystore – this is a limitation on SMP.

Ok – two more steps, first we import the cert then we rename it to smp_crt. To import the cert we use the command:


keytool -importkeystore -srckeystore myNewSMPCert.pfx -destkeystore smp_keystore.jks -srcstoretype pkcs12


At this stage you will be prompted for the password for your keystore as well as your new certificate both of which should match. Now we have the certificate in we need to rename it or rather change the alias. To do this we first need to see what the current alias name is by running the list command we ran above earlier and identifying the cert we just imported. I usually do this by the cert date which I compare to the certificate. The lengthy string to the left of the date is the current alias of your certificate so simply copy it – it will look something like:

/wp-content/uploads/2014/11/1_582658.jpg

So the next command I run is to tell the keystore to take that certificate and rename the alias to smp_crt as follows:


keytool -changealias -alias "le-5ba8d3f9-dfa6-5e72-b488-ef3f76acae35" -destalias "smp_crt" -keystore smp_keystore.jks


Obviously replace the long HEX string with your own string and enter the passwords when prompted (they should all be the same).

And that is it for the SMP server, if you restart your SMP instances now and reload your browser (you may need to clear the cache) you will see that the certificate used to secure the communications is now the one you provided and hopefully one your browser trusts (if your setup is right).

SMP MBO 3.0 sidecar

The second area where you may have SSL certificates is of course on the old MBO sidecar. For MBOs there are, again, a number of ports we need to concern ourselves with:

2481 – for secure RBS (replication based sync) communications

8001 – for secure Web/REST communications

8283 – for the MBO sidecar admin console (the SAP Control centre)

The first two ports are pretty easy to update and can all be done from within the SCC. Simply log into your SAP Control centre (port 8283) and go to the configuration area on the left, then select the General tab and go to the SSL Configuration section. Once in there you can import a new certificate using the “Key Store Configuration” button.

/wp-content/uploads/2014/11/2_582836.jpg

Once in there use the “Import” function to upload the certificate selecting the type PKCS #12, a sensible alias and the password for the certificate. For me a sensible alias for my cert is something like “<serverHostname>-<CAName>” for example for the server SMP01 and CA myCA1 it would be SMP01-MYCA01.

Once this is uploaded you can adjust the security profile to use the new certificate. Simply change the default values below to match your new alias above and save to activate your certificate. And that is it for ports 2481 and 8001 once you restart your MBO sidecar services.

/wp-content/uploads/2014/11/3_582846.jpg

One more to go now – the certificate presented for the SAP Control Centre. This is slightly more….hidden

In this case we need to replace the certificate with the alias “jetty” in the keystore in SMP_HOME\SCC-3_2\services\EmbeddedContainer\keystore. The default password for this keystore is changeit unless it has been changed by your installer. The process to replace the certificate is the exact same as we did above:

  • Backup the keystore
  • List and identify the cert to be replaced (frequently there is only one cert in this keystore)
    • keytool -list -keystore keystore
  • Delete the existing cert with the alias “jetty”
    • keytool -delete  -alias jetty -keystore keystore
  • Import your new certificate
    • keytool -importkeystore -srckeystore myNewSMPCert.pfx -destkeystore keystore -srcstoretype pkcs12
  • Change the alias to match “jetty”
    • keytool -changealias -alias “le-5ba8d3X Y Z6acae35” -destalias “jetty” -keystore keystore
  • Restart all MBO services including the SCC

And that is it – you should have all SSL enabled ports presenting valid certificates now. SAP recommend using a wildcard certificate for multi-node environments (e.g. *.mycorp.com) as this makes the distribution work amongst many nodes.

Any questions/comments most welcome below.

Brenton.

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Muralidharan Surendran
      Muralidharan Surendran

      Very good document. I agree I am often surprised why most of the implementations leave the certificate to the end of the project. I am currently in an WM implementation and we already have this in place and its actually fairly a simple to get around, once the basics are understood.

      Author's profile photo Former Member
      Former Member

      This document is very helpful.

      One thing you might want to add is instructions to handle a case where your CA uses an intermediate certificate.  In this case, you need to concatenate (in this order) the CRT format certificates before combining the chain with the private key to produce the P12:

      (1) your certificate

      (2) intermediate authority

      (3) root authority


      NOTE: be sure to leave the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" boundaries intact.  It is OK to add a carriage return between certificates so these boundaries are on separate lines.


      I converted this concatenated chain of CRTs into a P12 while adding the private key with this command:


      openssl pkcs12 -export -in cert_chain.cer -inkey myserver.key -out cert_chain.p12


      THANKS!

      Author's profile photo Brenton OCallaghan
      Brenton OCallaghan
      Blog Post Author

      Absolutely - thanks for the addition Doug - I was indeed using a root cert at the time so didn't come across this 🙂 but it's a very good point and thanks for sharing!

      Thanks again,

      B

      Author's profile photo Ralf Berhorst
      Ralf Berhorst

      I appreciate this very extensive document! 🙂

      I still work with a 2.3.6 system and i am not able to replace the default SSL/certificate with a one from our companies CA.

      I think the problem is, no default password is set on the keystore file. Therefore i am not able to set a new one. But all keystore modification required a password min. 6 characters.

      Question belongs to this document - does this very basic SSL/Certificate setting is the same in 2.3.6?

      Does anybody know how to set the password of the keystore without a default password?