Hi, welcome to SAP Digital Partner Engineering.
I am Denys van Kempen
In this video tutorial series, we will who you how you can configure a secure Reverse
Proxy for SAP HANA Live Connection for use with SAP Analytics Cloud.
This is video number three.
This video has been recorded in June 2019.
For earlier or later releases, please check the playlist.
In the description below there is a link to the playlist and to the blog with background
information and the commands executed.
OK.
In the previous video we installed Apache and configured reverse proxy for regular HTTP.
In this video, we are going configure Apache for HTTPS, secure HTTP, with certificates.
To start with, let’s generate a dummy certificate first for testing.
For this we can use gensslcert.
This utility comes from SUSE, if not mistaken.
It is included when you install Apache using YaST as we did in a previous video.
Let’s pause this for a second.
When executed without parameters it will generate a dummy certificate.
Note that the CN, the common name, is hxehost.localdomain, this is the output of the localhost -f command.
C, country = XY, o, organisation = SUSE Linux web server, just random input for testing.
A certificate authority key is generated.
This assumes the role of a root authority.
With this key a private key for the server is created.
The whole infrastructure is set up.
When we list the contents of the four SSL directories under Apache2, we can see them.
We have SSL dot CRL for certificate revoke list.
There is nothing there and we are also going to keep it that way.
There is CRT.
Here we have the server certificates.
We have a CA, certificate authority certificate and a server certificate and together they
make the certificate chain.
There is CSR.
These are the certificate sign requests.
You would submit these to the root authority like DigiCert or Symantec, but not when using
dummy certificates, of course.
We will skip them for now.
There is SSL.key, this is our private server key. and we have SSL.PRM, parameter files,
empty, also not relevant for our purpose here.
In the previous video, we also already talked about the Apache configuration files, the
CONF files in the apache2 home directory.
In this case, we get to see the SSL one.
We do not edit these files directly.
We are going to use YaST.
Use yast http-server this time, short cut We need to go to Server Modules (alt S)
and enable SSL.
Same as we did before to enable reverse proxy.
We can verify this when we cat sysconfig apache2 It is a long file, so lets just grep APACHE_MODULESand
we can see that SSL is now loaded Again, no need to edit loadmodule.conf
It is generated.
Here we have the entry OK
Like with reverse proxy, all we need to do is create a local conf file with our own server
specific settings.
For reverse proxy, we did this in the conf.d directory, for generic configurations.
For SSL, we are going to link this to a virtual host configuration and we do this in the vhost.d
directory.
Here we have a couple of template files for us to use.
Only files with the conf extension are loaded, so lets make a copy of the template file,
give it the conf extension and edit the file We only need to make a couple of changes.
ServerName needs to correspond to the CN, the common name, in the certificate.
ServerAdmin is optional The log file and DocumentRoot we can leave
as is.
We already saw that this will return a 403 access denied.
We do need to point to the right private key and the right server certificate
With a substation in vi we can do this in one go.
OK.
We can check that we go the paths right and now we can reload apache
and check the status The error we see here, by the way, was returned
because yast, or systemd to be precise, tried to restart apache after we enabled SSL but
before we edited this file.
Could not find the certificates (syntax error) and reload failed.
OK Let’s try it out.
Remember, clicking the external IP link, the URL, in the cloud console will automatically
attempt to access the server using HTTPS … and … it works
We get an error Let’s open the developer tools
and go to security We can see that the connection is secure,
connection is encrypted.
The plumbing works but a certificate is missing.
We can view the certificate.
Country XY, Organisation SUSE Linux, the default parameters we saw earlier with common name
hxehost.localdomain but the browser is missing a root certificate from the certificate authority,
the CA.
Anybody can claim to be hxehost.localdomain we need a trusted CA to validate this claim.
This we do not have, we is our browser, so we get an error.
but SSL is working just fine.
When we use another browser, Firefox for example, we get the same result
Error code: Unknown issuer View certificate returns same result.
OK.
If we accept the rusk and continue, we get the 403 we saw earlier.
So, we are connected over HTTPS, we just need to fix the certificate.
Now, if we return to gencert Note that the CA certificate, the root certificate
was copied to the DocumentRoot.
This we can download to our client and tell our browser this is the root certificate to
be trusted.
So when the browser then access the URL, it gets a certificate, matches it the root certificate,
gets an OK, and then we have established a secure connection.
Now when we list the permissions on the CA cert it is read only for root.
As a reminder, if we get the status process id is 23967
if we then list our process Here we have root, starting apache (as systemctl)
but then httpd forks run as wwwrun and wwwrun does not have access to this CA
file.
So if we change that to others + read, the wwwrun process can access the file
If we then also update our configuration file And specify that is OK to list the contents
of the directory restart apache
and refresh our page We now get to see the root certificate.
Select it, This behaviour is specific to Firefox
and we are asked to confirm to trust this server as new Certificate Authority
Select for websites We can view the certifcate.
Same as before.
OK Let’s remove the exception
Error code is Bad Cert Domain We are connecting using the IP but the certificate
says the CN is hxehost.localdomain We can put that in the URL but this only works
of course if we also resolve the name
So we need to add this entry to our local hosts file, IP address and the name in the
certificate and if we now refresh
No more warnings We have a secure connection, verified by the
Linux web server
What about Chrome?
Paste in the hostname
We still get a warning; your connection is not private
When we click Advanced, we can proceed.
The directory with the certificate is listed.
What we just did for Firefox did not affect Chrome.
So lets download the certificate and open it.
On the Mac, this works with KeyChain access; on Windows just double-click to import the
certificate.
Note that Keychain marks it as self-signed root certificate.
It has not been verified by a third party.
This is all correct.
We can indicate that we want it to be trusted.
but if we then refresh our page, we still get a warning.
When we look at the certificate, we can see that the certificate is valid and the CA is
trusted.
So, what’s wrong?
For this we need to open developer tools and it turns out that the subject alternative
name is missing.
Now this is specific to Chrome.
If we open Safari
Go to the hxehost.
The connection is encrypted.
So we have enabled SSL for Apache succesfully.
When we import the CA certificate, Firefox, Safari, and Internet Explorer are perfectly
happy.
OK; bonus track; we did not show Explorer
Here I am connected to a Windows computer.
First we need to update the local hosts file
Open a command prompt as administrator
Then in the drivers\etc directory, Notepad hosts
add fixed IP with fully qualified hostname
Open a browser and paste in the hostname
Access forbidden, that is correct.
We are on HTTP here.
We only specified directory listing on HTTPS, so let’s change the protocol
There is a problem.
That’s correct.
Self-signed certificates are a problem indeed.
Continue and we have certificate
The web server certificate is untrusted
Let’ download the root certificate.
Open it.
We are told what to do.
This CA root certificate is not trusted.
To enable trust install this certificate in the Trusted Root Certification Authorities
store.
OK
Install certificate
Current user of Local Machine.
That’s up to you.
Doesn’t matter.
OK.
Browse for the Certificate Store and select Trusted Root CAs.
We get a proper warning.
If we trust this as root certificate we are going to trust all the web servers downstream
as well.
Are you sure.
Yes.
And if we now look at the Certificate we can see the certification path.
OK, now to get rid of the error, we need to open a new tab.
hxehost has indentified this site as hxehost.
So Internet Explorer is happy, Firefox is happy, Safari is happy.
We have configured SSL for our Apache webserver but only Chrome disagrees.
This we will fix in the next video.
Thanks for watching.
You can find more video tutorials on our YouTube channel.
Please subscribe and join us.
If you are on LinkedIn, feel free to connect with us or follow us on Twitter or Facebook.
If you are watching this video on YouTube, do not hesitate to leave your comments to
the video page or post a questions, and, if you like, give us your vote on this video.
Denys van Kempen, SAP - Digital Partner Engineering Thank you for watching.