Intranet https client communication certificate requirement

Dear All,
I need your suggestion and feedback on SCCM client management using https (Intranet).
My client want to use https(443) intranet client’s communication instead of http(80)
Site system has MP, DP, SUP roles to manage two untrusted domain clients and few workgroup clients.
As per MS, there are three certificates needed to manage https environment.
Web server certificate
DP certificate
Client certificate.
For trusted domain, I will use auto enrollment of client certificate using group policy to deploy the certificates.
Here is my questions,
For Untrusted domain/work group client communication, do I need create individual certificate based on the hostname and deploy manually on the clients
Or
Do we have any other alternate method for certificate deployment?
Regards,
Kannan
cheers, kannan.cs

There are ways of scripting the installation and/or using web policy or web page enrollment but that doesn't the requirements and will still almost always lead to some manual intervention. That's the whole of AD -- centralized identity and authentication
and choosing not to join these systems to AD (for whatever reason) means you have chosen not to have have this centralized identity which means it will require some manual intervention (unless you have another management system in place already).
Jason | http://blog.configmgrftw.com | @jasonsandys

Similar Messages

SCCM Internet Based Client Communication

We have one primary server (which includes all the general roles) and two remote distribution points. Question is, after I configure the MP for internet clients (HTTP and HTTPS), setup the necessary PKI infrastructure, publish the site server FQDN to public
DNS servers, and install the internet client, how does it communicate back to the internal server? We don't have a DMZ and our primary site server is completely internal. If I add our external IP to public DNS the internet client can resolve this and our firewall
is open to HTTPS traffic. Once the client reaches the front facing IP how does it than contact a strictly internal management point and distribution point?

HTTPS client communication and IBCM don't change anything about how ConfigMgr works really. The traffic must still flow from the client to the client facing sites roles. Thus, you need to facilitate this flow of traffic no different than hosting a
web site that both internal users and users on the Internet access -- in fact, it is exactly the same from a network perspective.
Jason | http://blog.configmgrftw.com | @jasonsandys

Configure OWA to require a client ssl certificate only for external connection

Hello.
At now i migrated OWA client from Exchange 2003 to Exchange 2010 and faced with a problem.
I want to then external client (somebody like user from home PC) connect to Outlook Web App, client certificate will be required.
But then client connect (somebody from work PC) to internal Outlook Web App Url, Integrate Windows Auth will be used and client ssl certificate not required.
Is it possible? Or i need to enable Outlook Anywhere?

Hi,
Base on my konwledge, I don't think it is possible.
When you install Exchange 2003, only one Default Web Site in Internet Information Services (IIS). if you change the authentication method and enable SSL on OWA, client ssl certificate always be required whether it's external or internal.
I recommend you refer to the following articles:
http://www.msexchange.org/articles-tutorials/exchange-server-2003/mobility-client-access/Securing-Exchange-Server-2003-Outlook-Web-Access-Chapter5.html
http://www.msexchange.org/articles-tutorials/exchange-server-2003/security-message-hygiene/SSL_Enabling_OWA_2003.html
Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft.
Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.
Thanks.
Niko Cheng
TechNet Community Support

SOAP Receiver Adapter problem (client certificate required)

My Scenario is similar to described in https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3721. [original link is broken] [original link is broken] [original link is broken] I have two PI servers running on one machine. I am trying to post message HTTPS with Client authentication via SOAP adapter from one PI system to SOAP adapter of other PI server. I have done the following configuration.
PI Server AXD - (Client) - Receiver SOAP adapter
PI Server AXQ - (Server) - Sender SOAP Adapter.
Steps in AXD
1. I have created a certificate of AXD in the service_ssl view of key storage.
2. I have imported the AXQ public certificate in to AXD in the TrustedCAs of Key storage
Steps in AXQ
1. I have created a certificate of AXQ in the service_ssl view of key storage.
2. I have imported the AXD public certificate in to AXQ in the TrustedCAs of Key storage.
3. I have created a user in AXQ and assigned the certificate of AXD under usermangement in Security provider to this user.
4. I have added the AXD certificate under Client Authentication tab with require client certificate option checked in the SSL Provider.
5. I have assigned the user created in AXQ in the step above to the Sender Agreement.
Now when I post message from AXD with Configure Client Authentication checked (Here I have selected the certificate of AXD and view as service_ssl) I am getting the following error.
Exception caught by adapter framework: SOAP: response message contains an error XIServer/UNKNOWN/ADAPTER.JAVA_EXCEPTION - java.security.AccessControlException: client certificate required at com.sap.aii.af.mp.soap.ejb.XISOAPAdapterBean.process(XISOAPAdapterBean.java:884) at com.sap.aii.af.mp.module.ModuleLocalLocalObjectImpl0_3
Any pointer to solve this problem is highly appreciated.
Thanks
Abinash

Hi Hemant,
I have couple of questions. Why do we need to import certificate for SOAP WS-Security and from where I can get it?
As far as my scenario goes I am not using message level security.
Secondly what do you mean by TRUSTED/WebServiceSecurity? I don't see any such view inside the Key Storage. I can see a view named just WebServiceSecuity though.
Also I don't have a decentralized adapter installation rather I have two separate PI instances having their own central adapter engine.
Abinash

Receiver SOAP adapter SSL error - client certificate required?

Hi all,
Problem configuring SSL in XI 3.0 NW04 SP17....
I have followed the config steps from Rahul's excellent weblog at <a href="/people/rahul.nawale2/blog/2006/05/31/how-to-use-client-authentication-with-soap-adapter">How to use Client Authentication with SOAP Adapter</a> (my Basis team have done the Visual Admin steps) and am going through his example as it closely matches my requirement. So, I have a test receiver SOAP adapter sending messages to a web service URL defined for a sender SOAP adapter. My test scenario is:
Sender File -> Receiver SOAP -> Sender SOAP -> IDoc Receiver -> IDocs in R/3
The problem components are in italic and underlined above. My Receiver SOAP Adapter has the web service URL, Certificate Keystore Entry and View entered. If, in the Sender SOAP Adapter, I have an HTTP Security Level of HTTPS Without Client Authentication, the interface works fine (note that Rahul suggests you untick the User Authentication in the Receiver but with this Security Level, it seems to work with or without it).
The problem is when I set HTTPS With Client Authentication in the Sender. I then get the following error in the message monitor:
SOAP: response message contains an error XIServer/UNKNOWN/ModuleUnknownException - com.sap.aii.af.mp.module.ModuleException: java.security.AccessControlException: client certificate required caused by: java.security.AccessControlException: client certificate required at com.sap.aii.af.mp.soap.ejb.XISOAPAdapterBean.process(XISOAPAdapterBean.java:1111) at com.sap.aii.af.mp.module.ModuleLocalLocalObjectImpl3.process(ModuleLocalLocalObjectImpl3.java:103) at com.sap.aii.af.mp.ejb.ModuleProcessorBean.process(ModuleProcessorBean.java:250) at com.sap.aii.af.mp.processor.ModuleProcessorLocalLocalObjectImpl0.process(ModuleProcessorLocalLocalObjectImpl0.java:103) at com.sap.aii.af.mp.soap.web.MessageServlet.callModuleProcessor(MessageServlet.java:166) at com.sap.aii.af.mp.soap.web.MessageServlet.doPost(MessageServlet.java:421) at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java(Compiled Code)) at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java(Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Inlined Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java(Compiled Code)) at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java(Compiled Code)) at com.sap.engine.services.httpserver.server.Client.handle(Client.java(Inlined Compiled Code)) at com.sap.engine.services.httpserver.server.Processor.request(Processor.java(Compiled Code)) at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java(Compiled Code)) at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java(Compiled Code)) at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java(Compiled Code)) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code)) at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java(Compiled Code)) at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java(Compiled Code)) Caused by: java.security.AccessControlException: client certificate required at com.sap.aii.af.mp.soap.ejb.XISOAPAdapterBean.process(XISOAPAdapterBean.java:843) ... 22 more
Has anyone got any idea what this could be caused by?
Many thanks,
Stuart Richards

Have you configured the https port with that keystore entry?
Check out these links:
http://help.sap.com/saphelp_nw2004s/helpdata/en/b0/881e3e3986f701e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/5c/15f73dd0408e5be10000000a114084/frameset.htm
Regards,
Henrique.

Logout from an "https client authentication (public key certificate)"

Hi ,
I am using an https client authentication (public key certificate) to login to my ADF faces website
How can I logout form the application? It seems the session.invalidate() is not working because my login information is still displayed after running the logout method (below)
Note that this logout method was working well with the Form-Based Authentication.
Thank you
Jamil
public String logout() {
ExternalContext ectx = FacesContext.getCurrentInstance().getExternalContext();
HttpServletRequest request = (HttpServletRequest)ectx.getRequest();
HttpServletResponse response = (HttpServletResponse)ectx.getResponse();
HttpSession session = (HttpSession)ectx.getSession(false);
session.invalidate();
String temp = request.getContextPath() + "/adfAuthentication?logout=true&end_url=/faces/logout";
try {
ectx.redirect(temp);
FacesContext.getCurrentInstance().responseComplete();
} catch (Exception ex) {
System.out.println("Exception in logout()");
return null;
}

Can you try with the null chk.. as this piece of code is working fine for us
public void logout(ActionEvent evt) {> FacesContext fc = FacesContext.getCurrentInstance();
> HttpSession session =
> (HttpSession)fc.getExternalContext().getSession(false);
> HttpServletRequest request =
> (HttpServletRequest)fc.getExternalContext().getRequest();
> HttpServletResponse response =
> (HttpServletResponse)fc.getExternalContext().getResponse();
> try {
> if (session != null) {
> session.invalidate();
> }
> fc.getExternalContext().redirect(request.getContextPath() +
> "/faces/index");
> } catch (Exception exp) {
> try {
> fc.getExternalContext().redirect("/faces/Error");
> } catch (Exception ex) {
}> }
> }

DSEE Server certificate required on client side?

I have DSEE 6.3 working in my environment but I am not sure it's configured as it should be....
I am using tls:simple and everything works, the certificate store is setup with
the CA and LDAP server certificates on both the LDAP servers and clients.
Questions:
- I was expecting the LDAP client to only require the CA certificate however that didn't work!?
- Shouldn't the server present the server certificate and the client would accept it by validating against the CA certificate? Why would it need to have the server certificate as well?
- If I deploy the LDAP server certificates to the clients will they all need to be replaced/updated when the server certificate expires?
Additional info:
My DSEE server is configured to NOT accept certificate based client authentication.
All my certificates are valid when I check them with certutil -V
Edited by: smorris@ on Jan 5, 2009 8:58 PM

Hi,
I ended up getting a certificate signed by my internal CA and it worked just as expected.
I can only assume my CA certificate wasn't actually a CA...
Checking the output of the commands you suggested clearly shows this - I must have been blind when I ran this last time (or looking at a different cert).
I guess my question should now be - why was the certificate I created not a valid CA?
Create CA:
CA.sh -newca
Create certdb:
/usr/sfw/bin/certutil -A -n test-ca -t TC,, -d . -i testca.pem
Certutil output on this CA:
/usr/sfw/bin/certutil -d . -L
test-ca CT,,
/usr/sfw/bin/certutil -V -e -l -u V -d . -n test-ca
test-ca : Issuer certificate is invalid.
/usr/sfw/bin/certutil -d . -L -n test-ca
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "<snip>"
Validity:
Not Before: Mon Dec 08 01:57:47 2008
Not After : Tue Dec 06 01:57:47 2016
Subject: "<snip>"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
<snip>
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Basic Constraints
Data: Is not a CA.
Name: Certificate Comment
Comment: "OpenSSL Generated Certificate"
Name: Certificate Subject Key ID
Data:
<snip>
Name: Certificate Authority Key Identifier
Key ID:
<snip>
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Signature:
<snip>
Fingerprint (MD5):
<snip>
Fingerprint (SHA1):
<snip>
Certificate Trust Flags:
SSL Flags:
Valid CA
Trusted CA
Trusted Client CA
Email Flags:
Object Signing Flags:
Edited by: smorris@ fixed format

Client Communication Issues when attempting to retire old ADCS Certificate Authority

Hi,
SCCM 2012 R2 running on 2008R2. Single site.
We've been migrating our environment to a new SHA2 Microsoft CA and we're seeing issues when attempting to retire our old SHA1 CA server.
We've had a fully functioning PKI integrated SCCM environment for some time. No issues. All our clients have client certificates deployed via group policy.
We've spun up a new CA and installed new SHA2 distribution point and webserver certificates on the SCCM server.
We have added the new Root CA certificate to the trusted list in the site properties (both are now listed)
We have confirmed that new machine builds are receiving SHA2 client computer certificates via group policy.
Everything runs happily with the two CA servers configured and running. We would like to retire the old CA server but when we shut it down we find that all older clients (with the SHA1 cert) stop communicating with the management point.
Clients with the newer SHA2 computer certs continue to function. We assumed that the old CA server didn't have to be running for the SHA1 certs to still function. Are we incorrect?
Anyone able to explain what's happening?
Cheers!

Hi Jason,
No, we don't have CRL checking enabled in the SCCM site settings. As I understand it that tells the clients to check the site server against the CRL?
We think the issue is due to IIS attempting to check the client certificates against the CRL on the old CA (which is currently turned off)
For now we've temporarily disabled CRL checking in IIS while we attempt to migrate the old CRL to the new CA. All our clients are now talking happily to the management point.
All good. Cheers.

HTTP Client Sample Code for Communicating with PI 7.11?

Hi.
When we used XI 3.0 we used the testtool in the link bellow to send http messages into PI and get the URL.
[http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/66dadc6e-0a01-0010-9ea9-bb6d8ca48cc8|http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/66dadc6e-0a01-0010-9ea9-bb6d8ca48cc8]
Can I find a simuler tool for PI 7.11?
BR
Kalle

Hi Kalle,
please check PI HTTP Client under: http://code.google.com/p/sap-pi-http-client/.
To my opinion a good choice for simple sending of messages to PI via http.
But of course there are more sophisticated tools with scripting environments included like SOAP UI.
best regards,
Markus

Internet Based Client Communication can not be established

Hi,
I have one Primary Site Server and a Database Server. It was only using HTTP connection before. By reading several articles I created PKI environment and made SCCM communicate with a test client via https. I dont have DMZ, so I want to use the existing site
server for both internal and internet clients communication.
To test https communication, I installed MS Project while Client Configuration Manager General properties showed Client Certificate=PKI and Connection Type=Intranet. So obviously it can communicate via https on intranet.
To test HTTPS Communication on Internet side, I entered a public DNS manually on the client computer and deleted DNS records for that PC from DNS. I also editted hosts file on the client by entering sccm.mydomain.com with public ip address. I set firewall to
allow 443 on that public ip address.
I checked and the Client Configuration Manager General properties shows Certificate=PKI and Connection Type=Internet.
First I entered the address https://sccm.mydomain.com from the test client I see a IIS8 Web page. Then, I tried to get a report which shows installed programs on a computer and report result was not reflecting the latest changes I made. So I am not sure whether
https on internet is working or not.
I noticed that Client Configuration Manager Properties Network Tab, Internet Based Management Point (FQDN) is blank. I guess there should be sccm server internet address(sccm.mydomain.com). I installed client manually with the command below meaning
I already entered the internet address for SCCM but IBMP FQDN is blank.
ccmsetup.exe /usepkicert smsmp="sccm2012.mydomain.local" ccmhostname="sccm.mydomain.com" smssitecode="XYZ"
Please advise.
1. How can I test if https working on Internet Side?
2. Is it normal to have Internet Based Management Point (FQDN) as blank?
3. Is there anything wrong with the design I am trying to implement above?
Thanks a lot
Yavuz Selim Atmaca

Here's a guide I made (MP/DP in a DMZ) but it should work for your scenario.
http://www.systemcenterdudes.com/?p=193
Make sure that your certificate requirement are ok and that your server FQDN is publicly published and available.
You must have an internet FQDN in your client properties. You can enter it manually, use a script or by using the ccmhostnameproperties in your client installation. (as you did)
To test, I usually connect directly on the internet bypassing the corporate network. It's the best test you can made.
Your scenario and troubleshooting steps are fine, you're probably just missing a minor thing.
Benoit Lecours | Blog: System Center Dudes

Client communication port for workgroup servers

We have SCCM 2012 R2 Single Primary Site in intranet. We have PKI with ADCS 2012. We are in process of mirating to HTTPS communication using certificates. We have few servers in workgroup and we plan to manage those servers with configuration manager by
manually installing client and specifying smsmp=sccm fqdn. for lookup management point.
Can we change client communication port for these servers?
For successful client communication do we need to open any ports except 443 in firewall?
What all ports needed to be open in this scenario?

Hi,
You configure the Communications port for the MP in the site so they must use the same ports, you can configure alternate ports so if it cannot communicate on port 443 it tries the next port.
http://technet.microsoft.com/en-us/library/gg712276.aspx
443 is sufficient, the client will also try to communicate on port 10123 for Client Notification,
http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCsQFjAA&url=http%3A%2F%2Fblogs.technet.com%2Fb%2Fconfigmgrteam%2Farchive%2F2012%2F09%2F27%2Ffast-channel-for-system-management.aspx&ei=1dAhU7qqOIL8ygPb1IHQAQ&usg=AFQjCNF4_G2sZBMbDDtJa95LBx7EYYBrRw
But it should fallback to 443 if not available as well.
Regards,
Jörgen
-- My System Center blog ccmexec.com -- Twitter
@ccmexec

Lync 2013 certificate requirements for multiple SIP domains

Hi All,
I am engaged with a client in respect of a Lync 2013 implementation initially as a conferencing platform with a view to enabling EV functions (inc. PSTN conferencing) in the future. They initially need to support 30 SIP domains and eventually
around 100 SIP domains which is proving to be either not possible or severely cost prohibitive. Their current certificate provider, Thawte, can only support up to 25 SANs and have quoted them 5 figures. We tend to use GeoTrust as they are cheaper but they
appear to have a limit of 25 SANs. GoDaddy appear to support up to 100 SANs for a pretty reasonable cost. My questions are as follows:
Is there a way that I’m missing of reducing the number of SANs required on the Edge server?
Use aliases for access edge FQDNs - Supported by desktop client but not by other devices so not really workable
Don’t support XMPP federation therefore removing the need for domain name FQDNs for each SIP domain
Is there a way that I’m missing of reducing the number of SANs required on the Reverse Proxy server?
Friendly URL option 3 from this page:
http://technet.microsoft.com/en-us/library/gg398287.aspx
Client auto-configuration:
i.
Don’t support mobile client auto-configuration in which case no lyncdiscover.sipdomain1.com DNS records or SANs would be required.
ii.
Support mobile client auto-configuration over HTTP only in which case CNAME records are required for each SIP domain (lyncdiscover.sipdomain1.com, etc. pointing to lyncdiscover.designateddomain.com) but no SANs are required.
iii.
Support mobile client auto-configuration over HTTPS in which case DNS records are required for each SIP domain and a SAN entry for each SIP domains is also required. This is because a DNS CNAME to another domain is not supported over
HTTPS.
If the answer to 1 and/or 2 is no, are there certificate providers that support over 100 SANs?
How do certificate requirements differ when using the Lync 2013 hosting pack? I would think that this issue is something that a hosting provider would need to overcome.
Would the Lync 2013 Hosting Pack work for this customer? The customer uses SPLA licensing so I think is eligible to use the hosting pack but not 100% sure it will work in their environment given that client connections are supposed
to all come through the Edge where their tenants will be internal and also given the requirement for an ACP for PSTN conferencing.
Many thanks,

Many thanks for the response.
I was already planning to use option 3 from the below page for simple URLs to cut down on SAN requirement.
http://technet.microsoft.com/en-us/library/gg398287.aspx
What are the security concerns for publishing autodiscover over port 80? I.e. Is this only used for the initial download of the discovery record and then HTTPS is used for authentication? This seems to be the case from the following note on the below page:
http://technet.microsoft.com/en-gb/library/hh690030.aspx
Mobile device clients do not support multiple Secure Sockets Layer (SSL) certificates from different domains. Therefore, CNAME redirection to different domains is not supported over HTTPS. For example, a DNS CNAME record for lyncdiscover.contoso.com that redirects
to an address of director.contoso.net is not supported over HTTPS.
In such a topology, a mobile device client needs to use HTTP for the first request, so that the CNAME redirection is resolved over HTTP. Subsequent requests then use HTTPS. To support this scenario, you need to configure your reverse proxy with a web publishing
rule for port 80 (HTTP).
For details, see "To create a web publishing rule for port 80" in Configuring the Reverse Proxy for Mobility. CNAME redirection to the same domain is supported over HTTPS. In this case, the destination domain's certificate covers the originating
domain.”
I don’t think SRV records for additional SIP domain access edge is a workable solution as this is not supported by some devices.
As per the below article:
http://blog.schertz.name/2012/07/lync-edge-server-best-practices/
“The recommended approach for external client Automatic Sign-In when supporting multiple SIP domains is to include a unique Access Edge FQDN for each domain name in the SAN field. This is no longer a requirement (it was in OCS) as it is possible to
create a DNS Service Locator Record (SRV) for each additional SIP domain yet have them all point back to the same original FQDN for the Access Edge service (e.g. sip.mslync.net).
This approach will trigger a security alert in Windows Lync clients which can be accepted by the user, but some other clients and devices are unable to connect when the Automatic Sign-In process returns a pair of SRV and Host (A) records which do not share
the same domain namespace. Thus it is still best practice to define a unique FQDN for each additional SIP domain and include that hostname in the external Edge certificate’s SAN field”.
===================
1. Basically the requirement is to initially provide Lync conferencing services (minus PSTN conferencing) to internal, external, federated and anonymous participants with a view to providing PSTN conferencing and therefore enterprise voice services later.
2. The customer currently supports close to 100 SMTP domains and wants to align their SIP domains with these existing domains. The structure of their business is such that “XXX IT Services” provide the IT infrastructure for a collection of companies who
fall under the XXX umbrella but are very much run as individual entities.
Question:
Would you agree that I’m going to need a SAN for every SIP domain’s access edge FQDN?
Thanks.

Certificate Requirements / Best Practice for DR Pool

Good morning
I'm looking for clarification on the certificate requirements for DR. I already have both my primary pool and my DR pool built, and paired. At the time I configured there, I used two different certificates for each pool. I would really just prefer to use
one when we build the environment live.
Is there some reason I cannot just add *all* servers from both primary and DR pool into one cert as SANs? The subject name/common name of the cert doesn't *really* matter as long as both the pool FQDNs and all server FQDNs are in the Subject Alternative
Names, right?

It may work, but it's not the path Microsoft recommends:
https://technet.microsoft.com/en-us/library/gg398094.aspx. This is one of the reasons I always try use an internal certificate authority, even if I have to deploy one just for Lync, just so little items like this don't matter
much.
If it works, it's up to you. I'd base that decision on how mission critical the solution is. If it's your phone system, I'd follow Microsoft's guides to the letter so I'm not in a nightmare situation if I ever have to call Microsoft support.
If it's IM and P only, I'd be willing to let some things slide if it's saving you a lot of money.
Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer".
SWC Unified Communications
This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Can't login Lync suddenly, the error is" There was a problem acquiring a personal certificate required to sign in."

Dear all,
This is a real issue in working. Our company provides office 365 mailbox and its lync for users.
Recently, many users meet such issue of " There was a problem acquiring a personal certificate required to sign in."
The lync version is 2010 and even I removed lync2010 cache for user's profile, that user still can't login lync.
See below picture.
Please give help and show advice.
Franklin hong

Hi,
The issue may be caused by that the user’s security credentials were corrupted or an RSA folder on the user’s computer may be blocking authentication.
Here is a similar case may help you:
http://community.office365.com/en-us/f/166/t/80399.aspx
Best Regards,
Eason Huang
Eason Huang
TechNet Community Support

Error in scenario "FILE to HTTP(with SSL)" - HTTP client code 110 reason.

Hi friends,
Our scenario is as follows:
We are trying to send XML file from our SAP-XI to external tool "COMMunix XC" (a multi-protocol EDI platform tool).
We have configured " FILE TO HTTP(with SSL)" scenario (trying to connect HTTPS/port)
1. We have created RFC destination of type G and refered the same RFC in Communication channel (Adapter type: HTTP)
2. We have send the SSL Server certificate to other party and ensure that they have imported at thier end.
3. We have included the certificates from other party in our SAP XI STRUST under SSL Client (Standard) node.
4. We have tried " CONNECTION TEST " in the RFC destination created in type G (in STEP 1) and it shows the GREEN TICK at bottom, no other message nor any error message
When we trigger the communication we recieve the error: HTTP client code 110 reason in SXMB_MONI.
Please let us know if we have missed out some step.
What does error message indicate,
Regards,
Rehan

Hi Rehan,
I see that the PROCTIMEOUT was already at a very high value.
Does this occur for messages of a particularly large size? If yes, you could increase the parameter
icm/HTTP/max_request_size_KB = 2097152
This would need to be done in the sender/receiver system as well as XI.
Otherwise you could try reproducing the issue and checking the dev_icm log in the work directory, or go to SMICM -> Goto -> Display trace file
check for errors like NIECONN_REFUSED or "no service for protocol HTTPS" which can often be related to this type of issue.
Kind regards,
Sarah

Intranet https client communication certificate requirement

Similar Messages

Maybe you are looking for