After you install your SAP NetWeaver Portal, you will probably access it
using regular HTTP. So, you'll use a URL that looks like:
http://theportal.mycompany.com:50000/irj. If you use a logon form where
you enter your portal username and password, thiose details will be sent
to the portal server unencrypted, which means that a malicious person
could in theory find that combination.
But did you know that you can use secure sockets to access the portal? By default, the portal is installed with SSL enabled. This means that you can change your URL slightly so that instead of typing "http", you can use "https", but you also need to add 1 to the port number (the number after the :) so that your URL for the above example becomes https://theportal.mycompany.com:50001/irj.
However there are a few problems with this. Depending on your browser, you will probably get a screen that looks like either
or
This is because by default the portal's standard SSL certificate has a few problems. These are:
--it's self signed, which means your browser doesn't trust it;
--it's expired; and
--it's been issued for an unexpected web site, localhost, not the one in the URL you entered.
This can be seen by opening up the certificate details:
So, why has this happened?
First some certificate basics. They are a way to certify an identity to help set up a trusting relationship. For SSL type access, they identify the system you are connecting to, so that you don't end up at a phishing site. You as a user can also have a certificate, which then means the system you connect to knows who you are. An example of this user certificate is the SAP Passport which you can get from the SAP Service Marketplace. Once setup, this allows you to connect to the SAP Service Marketplace without having to enter your S-number and password. In effect, the SAP Marketplace web sites trust your passport.
The value of the server certificates for the portal are managed in the Key Store service of the Visual Administrator.
In the service_ssl view you can see the standard self signed certificate.
If you want to generate a certificate request for our real hostname instead of "localhost", use the "Create" option and enter appropriate values. The most important is the common name, which is the hostname from the URL that you use to access the portal.
After generating the new certificate, you need to send this to a Certification Authority (CA) who will sign it and then send it back to you. This normally involves a fee of some sort. SAP provides limited lifetime certificates for testing purposes. Details can be found at http://service.sap.com/ssltest.
From the same service we can see the available certification authorities (Trusted CAs) that we trust. This is important if we are going to use client certificates, such as an SAP Passport. Please note that CA certificates also have an expiration date.
The SSL provider service is where we specify which server identity (certificate) to use and, optionally, which client CAs we will trust. For example, if we decide to use SAP Passports to access the portal, then we need to trust the SAPPassportCA.
If we decide to request or require client certificates, this is where we specify the CAs to trust.
But did you know that you can use secure sockets to access the portal? By default, the portal is installed with SSL enabled. This means that you can change your URL slightly so that instead of typing "http", you can use "https", but you also need to add 1 to the port number (the number after the :) so that your URL for the above example becomes https://theportal.mycompany.com:50001/irj.
However there are a few problems with this. Depending on your browser, you will probably get a screen that looks like either
or
This is because by default the portal's standard SSL certificate has a few problems. These are:
--it's self signed, which means your browser doesn't trust it;
--it's expired; and
--it's been issued for an unexpected web site, localhost, not the one in the URL you entered.
This can be seen by opening up the certificate details:
So, why has this happened?
First some certificate basics. They are a way to certify an identity to help set up a trusting relationship. For SSL type access, they identify the system you are connecting to, so that you don't end up at a phishing site. You as a user can also have a certificate, which then means the system you connect to knows who you are. An example of this user certificate is the SAP Passport which you can get from the SAP Service Marketplace. Once setup, this allows you to connect to the SAP Service Marketplace without having to enter your S-number and password. In effect, the SAP Marketplace web sites trust your passport.
The value of the server certificates for the portal are managed in the Key Store service of the Visual Administrator.
In the service_ssl view you can see the standard self signed certificate.
If you want to generate a certificate request for our real hostname instead of "localhost", use the "Create" option and enter appropriate values. The most important is the common name, which is the hostname from the URL that you use to access the portal.
After generating the new certificate, you need to send this to a Certification Authority (CA) who will sign it and then send it back to you. This normally involves a fee of some sort. SAP provides limited lifetime certificates for testing purposes. Details can be found at http://service.sap.com/ssltest.
From the same service we can see the available certification authorities (Trusted CAs) that we trust. This is important if we are going to use client certificates, such as an SAP Passport. Please note that CA certificates also have an expiration date.
The SSL provider service is where we specify which server identity (certificate) to use and, optionally, which client CAs we will trust. For example, if we decide to use SAP Passports to access the portal, then we need to trust the SAPPassportCA.
If we decide to request or require client certificates, this is where we specify the CAs to trust.
No comments:
Post a Comment