Connecting SLS to Remote CA (CES/CEP)

[Colt]

Hi Experts,

I have started to get familiar with some new features of SSO 3.0 and decided to give it a try with the Remote CA configuration. In my demo-environment I got a 2008 R2 domain controller with forest and domain functional level set to 2008 R2. In addition on a different 2012 R2 server I operate a Enterprise Root CA (ADCS) with Certificate Enrollment Web & Policy Service (CES & CEP). The CA is running fine and based on certificate templates I am able to enroll certificates for domain users based on RPC/DCOM interfaces.

Now I want to use my existing CA for the Secure Login Server to allow SLS acting as a RA for my CA, after authenticating users via JAAS modules forwarding the certificate requests to my corporate CA. The information I was able to obtain from the Secure Login Implementation Guide for 3.0 was quite basic, unfortunately there is no information about how to setup ADCS, templates and which URI to be used and so on... I would love to get some more information about that.

But lets see what I have done so far:

• In addition to my CA role I've installed the two role services CES and CEP
• Did the configuration recommended by MSFT (Well, in my environment, the CA as well as CEP and CES services are running on the same host, which makes things easier for me and don't require delegation, but not recommended for productive use)
• For authentication I decided to start with Username and Password based authentication, makes things easier.
• + understand the concept behind CEP/CES

To begin with, CEP and CES Services seems to work fine, as I was able to enroll a certificate from a non-domain-joined computer via MMC certificate snap-in and by just adding the CEP URI and authenticating the user. This means the computer only use HTTPS traffic, based on the web service communication instead of using the former RPC/DCOM type of communication. Behind the scenes, now CEP will make the LDAP query to AD to determine the CA and Policy information and after receiving it provides the information back to the web service client. Based on the policy/template information received, the computer will know about the certificate templates available for enrollment and request a certificate based on a selected template by generating and sending a certificate request - now to the CES URI, again via HTTPS. CES now takes the request, impersonates the security context of the user and delegates the call to CA, via old school (ICertRequest) RPC/DCOM to submit the request to the CA. CA sends back the certificate to CES which in turn provides the certificate to the computer.

• Enrolled a certificate to a non-domain-joined computer

Steps:

Adding the CEP URI:

Retrieve friendly name from IIS App (CEP):

Receive templates allowed for my user account and select the default User template:

Authenticate the user with AD credentials:

If i look inside the details:

This works, i received my certificate via CES web services:

But that is all Microsoft standard Now the mission was to replace my computer with the SLS. However I was not able to figure out from the manuals more details, e. g. if the SLS wants to address the CEP or CES URI, so I tried with both.

My Secure Login Server 3.0 is able to reach the CES/CEP URI via HTTPS and without any Proxy. The issuer of the SSL certificate (IIS) is trusted in AS Java TrustedCAs store.

Steps:

Create a HTTP destination for the Remote CA in NWA:

Entered the URI of the CEP service - and as this was not working also tried with the CES URI - same result for both. Also specify the SSL store for CA chain validation of the CES web service SSL certificate:

Specified the Basic authentication and Username + Password (also tried with DOMAIN\<USER>)

No luck with the ping (received a HTTP 400 message)

Question: Anything I haven't considered at this stage?

Not really motivated by the PING result, I moved on to the SLAC and added a Remote-CA by specifying a Entry Name, the Adapter type "ADCS - WebEnroll" and the HTTP Destination which the SLS automatically figured out.

Knowing the fact that I would have no success, I pressed the "Test" button (whatever it does) and received a exception / HTTP 415 error message.

Well thats the current status so far. Hopefully someone (Stephan) is able to help me out here?

Are there any recommendations for ADCS setup from SAP in order to use the SLS for Remote-CA? What is the interrelation between CA templates and SLS, which types of Templates are supported, any restrictions? Known limitations when using the Remote-CA feature in SLS 3.0 at this stage (SP0)? And it would really help if you have something like a implementation guide or cook book for configuring SLS 3.0 using Remote-CA to use a ADCS CES/CEP.

Cheers,

Carsten

[former_member200373 · Accepted solution]

Hi Carsten,

SLS 3.0 SP00 only supports "Simple CMC" and "ADCS WebEnroll" (ADCS role "Certification Authority Web Enrollment).

And for ADCS WebEnroll, we have a limitation to one named ADCS certificate template, "SecureLoginServerUser". You cannot change this template name, and here can be only this one.

We plan to extend our remote CA adapters in SP01:

- ADCS WebEnroll adapter to support all SLS certificate templates,

- and a new adapter for ADCS NDES, supporting up to three certificate templates.

For the time being, you can get ADCS WebEnroll running as follows:

1. Set up ADCS to support Web Enrollment. Test with Internet Explorer, something like https://sapsso-ads-dev.mo.sap.corp/certsrv. Log in as domain user.
2. Create a new AD user like DOMAIN\SLSRA. Care for proper security settings.
3. Create a ADCS certificate template named "SecureLoginServerUser".
4. In this template, turn on "Security > Autoenroll" for DOMAIN\SLSRA (and no other domain user)
5. Also turn on "Subject Name > Supply in the request".
6. Check that "Cryptography > Minimum key size" fits to your SLS profiles.
7. Back in NWA, configure your HTTPS destination with DOMAIN\SLSRA as basic auth user.
8. [Alternatively, create a PFX key file for DOMAIN\SLSRA, import it into an NWA certificate view, and turn on HTTPS X.509 client auth in the NWA destination as well as in IIS. Don´t do this before basic auth was running successfully, otherwise things become complex.]
9. Ping should work now. If not, check your IIS ports and sites configuration.
10. Back in SLS, create a fresh "Remote CA" using the new HTTPS destination.
11. "Test Remote CA" should work now.

-- Stephan

[Colt · Accepted solution]

Thanks for clarification Stephan!

The web enrollment was something I have tested before with success, but i wasn't aware about the details e. g. template name and the other restrictions with SP00. Seems there is some work to do in order to update the manuals

I will try and keep you posted. At the moment seems the SLS Remote CA feature indeed is limited to user certificates only and not to be combined with Cert Lifecycle Mgmt for enrollment and renewal of SAP server auth certs. I am looking forward to further SPs.

BTW: So CES/CEP is not supported, right?

Cheers,

Carsten

[Colt · Accepted solution]

Hi Stephan,

just a quick update. I've setup all steps carefully and able to enroll a certificate for SecureLoginServerUser via web enrollment (certsrv) manually. RFC destination pings fine but in SLAC after creating the fresh remote CA and testing with CN=TEST it returns "Remote CA connection error with HTTP status 404". I am now searching for the root cause and J2EE logs doesn't really help - not much details. The user has Read, Enroll and Autoenroll Permission on the template and manually requesting a cert over the certsrv website using that user works.

Cheers,

Carsten

[Former Member · Accepted solution]

Just a short note to be on the safe side as it can be a source of confusion. RFC destination distinguishes between physical pings and application pings.

The "Connection test" is a physical ping and no authentication takes place - consequently the user does not even have to exist as no AUTHORITY-CHECKs take place.

The "Test -> Authorization test" is an application ping which calls an ABAP function - consequently authorization is required and invokes authentication to verify whom to perform the AUTHORITY-CHECK against and that user must exist.

-> So a successful ping does not mean that the application will work fine.

Cheers,

Julius

[Colt · Accepted solution]

Hi Julius, thanks for the notes. Indeed in J2EE destination of type HTTP it performs (in my case) basic authentication with a valid user. Doing that i get the response code 200 (Content type text/html). Doing the same with a invalid password i get http error 401. So based on that I was able to exclude wrong authentication. Cheers, Carsten

[kuhnen · Accepted solution]

Hi Carsten,

Does the HTTP Destination URL looks like https://hostname ? or https://hostname/certsrv?

Be aware that only https://hostname works.

Regards,

Marcus

[kuhnen · Accepted solution]

Hi Stephan,

the HTTP Destination URL to the ADCS should be https://sapsso-ads-dev.mo.sap.corp

/certsrv should be removed.

Regards,

Marcus

[Colt · Accepted solution]

Hero!!! Thanks Marcus, works now! Seems to be my fault also not to be found in the Implementation guide of SSO 3.0 either

[former_member200373 · Accepted solution]

OK - for SP0, the Web Enroll adapter requires https://sapsso-ads-dev.mo.sap.corp only. Sorry again.

[shashi046]

@crm_001 i am also looking for the same ,did you get this figured out?

[Colt]

2375797 - Secure Login Server 3.0 - Remote CA Configuration

[crm_001]

Dear Carsten,

Can you please help on the below issue--

I’m also trying to integrate SLS 3.0 with an external PKI structure. I created the required HTTPS destination but somehow the ping destination test is failing with the below error message ” Error during ping operation: Error while silently connecting: org.w3c.www.protocol.http.HttpException: Connection Reset”.
P/S- I’m able to access the PKI Web Service URL with the authenticated domain user and used the same user in the HTTPS destination as well.

Please advise..

Thanks in advance !!

[Colt]

Anyone?