No switch to HTTPS occurred, so it is not secure to send a password

[Former Member]

Dear colleagues,

1. We do have SRM-ABAP system : DL9

2. We do have SRM-Portail system : DJ9

3. DL9 (ABAP stack) is defined as back-end system in DJ9.

4. The 3 connections tests perfectly works :

4.1 SAP Web AS Connection ==> OK

4.2. ITS Connection ==> OK

4.3. Connection Test for Connectors

5. I did not defined any https option.

Then, when I am logging to the portal, I will open the "Employee Self-Services" Menu.

I get this popup :

No switch to HTTPS occurred, so it is not secure to send a password

Question :

Is there a specific JCO to create to loggin to "Employee Self Services" ?

Thanks in advance for your input.

Best regards

P. Cuennet

[Former Member · Accepted solution]

Hi,

ESS has to be connected to the HCM module of an ECC6 back office system.

It is not possible to use an SRM abap system as an ESS back office system.

There are several JCO connections to configure for ESS/MSS.

This is well explained in help.sap.com.

(I assume that you are speaking about ESS/MSS = XSS).

Regards,

Olivier

[Former Member · Accepted solution]

Dear Olivier,

Thanks for your input.

I was not explicit enough.

In fact :

When I am loggued in DJ9 (System units = AS-JAVA, SRM-JAVA, EPCore, EP), I want to loggin to DL9 (SRM-Server ABAP).

I click on "Employee Self-Service" - I get this warning :

No switch to HTTPS occurred, so it is not secure to send a password

Even if the connection of "Employee Self-Service" is linked to an ERP instead and SRM-ABAP server,

I have this error.

This is typically a configuration problem.

This is very strange because in DL9 definition as back-end system, I do not use "https" :

1. Authentication Ticket Type = SAP Logon Ticket

2 Logon Method : SAPLOGONTICKET

3. ITS Protocol : http

4. Web AS protocol : http

I never choose https in my DL9 back-end system configuration.

So why do I have to loggin to DL9 when I start "Employee Self-Service" from DJ9 ?

Any inputs are very welcome.

Best regards

P. Cuennet

[Former Member · Accepted solution]

Hi Pascal,

I don't understand what you call Employee Self service in an SRM context but anyway,but it seems that the saplogon ticket from DJ9 is not accepted in your DL9 abap system. (and that https is not configured in DL9)

Did you import the SAPLogonTicketKeypair-cert.cer certificate file from DJ9 in transaction STRUSTSSO2 of DL9 ?

Regards,

Olivier

[Former Member · Accepted solution]

Hello Olivier,

Thanks for your input.

Yes, I have imported the DJ9 certificate in DL9.

By starting SSO2 transaction and NONE as RFC, there is no error.

There is also no error to test the connection from DJ9 to DL9.

I am just wondering why I have to re-log to DL9 from "Employee Self-Service" as far as the SSO is configured between

DJ9 and DL9.

In DL9, I have set the following instance parameters :

1. icm/host_name_full = sl1srmdev.neo.local

2. login/accept_sso2_ticket = 1

3. login/create_sso2_ticket = 2

Best regards

P. Cuennet

[Former Member · Accepted solution]

Hello Pascal,

>There is also no error to test the connection from DJ9 to DL9.

What do you mean ? Which kind of connection do you test ? JCO ? HTTP ?

Are your DJ9 and DL9 systems in the same domain ?

Do tou use the FQDN of DJ9 server when connecting to the portal ?

Regards,

Olivier

[Former Member · Accepted solution]

Hello Olivier,

1. We are using http connection.

2. Yes, they are in the same domain.

I can loggin. When I click on "Employee Self-Service" from DJ9, I just get a popup asking me to

enter my user and pwd of DL9. After, I can reach the DL9 system without problem.

I am just wondering why when I am already loggued in DJ9, I have to re-log to DL9 to reach "Employee Self-Service"

3. Yes, I am using the FQDN in definition of DL9 as back-end system of DJ9.

In DL9, I have set the following instance parameter :

icm/host_name_full.

Best regards

P. Cuennet

[Former Member · Accepted solution]

Hi again Pascal,

If your config is as you tell, it should work. So I think there is an error in your configuration.

My advice is to use an HTTP trace tool ( personally , I use Httpwatch) and to trace the creation and the domain of the MYSAPSSO2 cookie and to verify if it is sent to the DL9 abap system.

Regards,

Olivier

[Former Member · Accepted solution]

Hello Olivier,

I do not have an error, this is just a warning.

In WebDiagTool report related to this session, I do no have any error.

I have also started the report RSPOR_SETUP.

I have no error.

The following lijnk is very interesting too :

I have increased the trace level of DL9 DIALOG process (OSS Note 701205 is very interesting).

N Thu Jun 24 09:34:06 2010

N dy_signi_ext: PASSWORD logon w/o ticket request

N DyISigni: client=100, user=SAPJSF , lang=E, access=R, auth=P

N usrexist: effective authentification method: <client,username,password>

N chckpass: client=100, user=SAPJSF , accesstype=R

N password logon is generally enabled (default)

N productive password is still valid (expiration period=0 / days gone=0)

N codvn=G => password is case-sensitive and up to 40 chars long

N chckpass: correct password

N Get_RefUser(100,SAPJSF) =>

N password logon is generally enabled (default)

N productive password is still valid (expiration period=0 / days gone=0)

N password change not required (expiration period=0 / days gone=8)

N usrexist: update logon timestamp (M)

N save user time zone = > < into spa

N DyISignR: return code=0 (see note 320991)

I will search in OSS Note 320991.

In any case, many thanks Olivier for your feedback.

Best regards

P. Cuennet

[Former Member · Accepted solution]

Dear SAP,

I have increased the trace severity in DL9.

I get the following log :

What I did :

1. I have check the 3 connectons started from back-end systems. There is no error.

2. I have re-imported portal certificats (DJ9) in DL9.

3. There is no JCO RFC provide error between DL9 and DJ9.

In DL9, in SM50, I have traced a DIA process and I get the following log :

=====================================================================================================

N Fri Jun 25 14:25:59 2010

N password logon is generally enabled (default)

N productive password is still valid (expiration period=0 / days gone=0)

N password logon is generally enabled (default)

N productive password is still valid (expiration period=0 / days gone=0)

N password change not required (expiration period=0 / days gone=8)

N InternetUserLogon called in testmode => 'authenticate-only'

N dy_signi_ext: PASSWORD logon with ticket request

N DyISigni: client=100, user=DUTOITP , lang=E, access=U, auth=P

N usrexist: effective authentification method: <client,username,password>

N chckpass: client=100, user=DUTOITP , accesstype=U

N password logon is generally enabled (default)

N productive password is still valid (expiration period=0 / days gone=0)

N codvn=G => password is case-sensitive and up to 40 chars long

N chckpass: correct password

N password logon is generally enabled (default)

N productive password is still valid (expiration period=0 / days gone=0)

N password change not required (expiration period=0 / days gone=8)

N usrexist: update logon timestamp (M)

N DyISigni: return code=0 (see note 320991)

N mySAPWrapTicket was called.

N Got Codepage 4103 for ticket creation.

N mySAP: Got the following SSF Params:

N DN =CN=DL9, OU=I0020603874, OU=SAP Web AS, O=SAP Trust Community, C=DE

N EncrAlg =DES-CBC

N Format =PKCS7

N Toolkit =SAPSECULIB

N HashAlg =SHA1

N Profile =M:\usr\sap\DL9\DVEBMGS00\sec\SAPSYS.pse

N PAB =M:\usr\sap\DL9\DVEBMGS00\sec\SAPSYS.pse

N login/create_sso2_ticket = 2 found. No certificates included in signature.

N Added client 100 and sysid DL9 to ticket contents.

N Added date 201006251226 to ticket contents.

N Ticket expiration time 8:00 found.

N Got user DUTOITP for ticket creation.

N mySAPWrapTicket: Trying to insert newly created ticket into ticket cache.

N HmskiInsertTicketInCache: Trying to insert logon ticket in ticket cache.

N HmskiInsertTicketInCache: Inserted new ticket into logon ticket cache with cache key: 100:3064128C40987A30790A127357C3CB1E .

N HmskiInsertTicketInCache: Inserted new ticket into logon ticket cache with cache info: <USER>=DUTOITP ,<CLIENT>=100,<LANGUAGE

N mySAPWrapTicket returns 0.

N dy_signi_ext: ticket created (600 chars)

================================================================================================

Any helps is very welcome !

Best regards

P. Cuennet

[Former Member · Accepted solution]

Dear Olivier,

You were right.

I have configured the ABAP back-end system using FQDN.

But when I open my web page, I did not used the FQDN.

With FQDN (Full Qualified Domain Name), it works.

Only with hostname name, I have to re-log.

Thanks again Olivier !

Best regards

PCuennet

[Former Member · Accepted solution]

Hi Pascal,

I'm glad you could solve your problem.

SAP SSO is based on the MYSAPSSO2 cookie.

A cookie is only sent to the other systems in the same domain, hence the necessity to use the FQDN !

Regards,

Olivier

[Former Member · Accepted solution]

Hello,

I am having the Same Error,

Where in i have IDS ( ABAP + JAVA) in which i have ESS configured to Same system ABAP stack,

And i have SRM system P01 To which i have connected the EP with SAP_SRM,

When i login to EP and login to ESS first time it askes for User name and Password and after that if i login with different user to Portal but in Backend ERP system it takes Same User As first user.

Please let me know as i have struck with issue from so many days.

Thanks & Regards,

Balaji.S

[Former Member · Accepted solution]

Hello Balaji,

In my case, the error were the following one :

1. When I am connected with hostname only "http://sl2srmdev:50000/irj/portal" to connect on my DJ9 system, I get the error "No switch to HTTPS occurred, so it is not secure to send a password" and I have then to re-log to DL9 (back-end ABAP system).

2. When I am connected with the FQDN (Full Qualified Domain Name "http://sl2srmdev.neo.local:50000/irj/portal" on my DJ9

system, I do not have to re-log to DL9 (back-end ABAP system).

Hope it helps.

Best regards

P. Cuennet