Skype For Business Certificate Error Clock Settings Mac

1. Skype Certificate Error
2. Skype For Business Settings Registry

The Skype for Business on Mac Client is available for download. Hardware and software requirements for Skype for Business on Mac. The Skype for Business on Mac client requires Mac OS X El Capitan and higher, and uses at least 100MB of disk space. We support the use of all built-in audio and video devices. External devices must be in the Skype.

1. Certificate creation and requirements for Skype for Business / Lync integrations. Pexip Infinity supports the use of Base64-encoded X.509 SSL/TLS certificates. Such certificates are used when integrating Pexip Infinity with Microsoft Skype for Business and Lync., either as part of an on-prem deployment or when deploying Pexip in a public DMZ for enabling direct federation with remote SfB/Lync.
2. Install Certificate for Skype for Business client (for Workgroup)1. Prepare- DC1: Domain Controller(Yi.vn) DC2: Certificate Server DC3: Sk.
3. Unfortunately, some Macs kept this expired certificate and stored it in their Keychain Access app. For now, the fix requires manually removing the expired certificate from your machine. Click the magnifying glass in the upper-right hand corner of your screen and type 'Keychain Access' and hit Return.
4. Certain features and behaviors that are available to Skype for Business Mac clients are determined by preference settings on the client. You can standardize the settings for Skype for Business Mac in your organization by configuring preferences for the application.

'Cannot sign in to Skype for Business because your computer clock is not set correctly. To check your computer clock settings, open Date and Time in the Control Panel.'

Pexip Infinity supports the use of Base64-encoded X.509 SSL/TLS certificates. Such certificates are used when integrating Pexip Infinity with Microsoft Skype for Business and Lync*, either as part of an on-prem deployment or when deploying Pexip in a public DMZ for enabling direct federation with remote SfB/Lync environments.

For an on-prem integration between SfB/Lync and Pexip Infinity, it is common to use an internal/enterprise Certificate Authority (CA) for requesting and creating certificates. However, for a public DMZ deployment of Pexip Infinity, a certificate from a public TLS/SSL certificate vendor/CA such as for instance Verisign, Comodo or GlobalSign is required.

We strongly recommend that all Pexip InfinityConferencing Node certificates should have both 'Server Authentication' and 'Client Authentication' Enhanced Key Usage properties.

This topic covers:

General information on managing certificates within Pexip Infinity can be found at Managing TLS and trusted CA certificates.

* Note that where this documentation refers to 'SfB/Lync', it represents both Microsoft Skype for Business and Lync unless stated otherwise.

Creating a certificate signing request (CSR)

The on-prem and public DMZ SfB/Lync integration guidelines both recommend that the same single certificate is installed on all Conferencing Nodes. This provides support for redundant Conferencing Node deployments and multiple SIP domains for SfB/Lync federation. Therefore, the certificate created for the Conferencing Nodes will typically need to contain multiple SANs (Subject Alternative Names). This type of certificate is also known as a UC certificate.

While this means that this single certificate will potentially contain a relatively high number of names, the administrator only has to manage a single SAN certificate across all Conferencing Node (unless multiple domain/subdomain support is required).

Wildcard TLS certificates are not supported in SIP or Microsoft Skype for Business / Lync environments (as per RFC 5922). If you are using SIP or Skype for Business / Lync, your Conferencing Nodes must not use wildcard TLS certificates.

You can use Pexip Infinity's inbuilt Certificate Signing Request (CSR) generator to assist in acquiring a server certificate from a Certificate Authority. Alternatively, you can use third-party tools such as OpenSSL toolkit.

Public DMZ environment requirements

When requesting certificates for Conferencing Nodes for public DMZ deployments:

• The Subject name (commonName attribute) should be set to the target hostname referenced by the _sipfederationtls._tcp SRV record (the pool name of the Conferencing Nodes).

  In our examples, if the DNS SRV record is:

  _sipfederationtls._tcp.vc.example.com. 86400 IN SRV 1 100 5061 px.vc.example.com.

  then the Subject name must be px.vc.example.com

• The Subject Alternative Name (altNames attribute) entries must include:

  • the target hostname referenced in the Subject name
  • the FQDNs of all of the public DMZ nodes that are involved in call signaling
  • the domain names that are used in any DNS SRV records that route calls to those Conferencing Nodes (e.g. vc.example.com from the example _sipfederationtls SRV record above).
• Assign the same certificate to all of the public DMZ nodes that are involved in call signaling.

See Assigning publicly-issued TLS server certificates to Conferencing Nodes for more information and examples for a public DMZ deployment.

On-prem environment requirements

When requesting certificates for Conferencing Nodes for on-prem deployments:

• The Subject name (commonName attribute) must be the Trusted Application Pool FQDN (such as confpool-eu.vc.example.com in our examples).
• The Subject Alternative Name (altNames attribute) entries must include the Trusted Application Pool FQDN (i.e. a repeat of the Subject name), plus the FQDNs of all of the nodes in the pool that are involved in signaling.
• Assign the same certificate to all of the enterprise nodes that are involved in call signaling.

See Assigning the certificate to Conferencing Nodes for more information and examples for an on-prem deployment.

Comparison of public DMZ and on-prem examples

When using Pexip Infinity's inbuilt CSR generator the examples below show the entries that would be required to match our example public DMZ deployment, and our example on-premises deployment (for the Europe-located pool of Pexip nodes):

See Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business / Lync and Certificate and DNS examples for an on-premises integration with Skype for Business / Lync for more information.

Adding additional nodes in the future

Pexip Infinity supports the use of Base64-encoded X.509 SSL/TLS certificates. Such certificates are used when integrating Pexip Infinity with Microsoft Skype for Business and Lync*, either as part of an on-prem deployment or when deploying Pexip in a public DMZ for enabling direct federation with remote SfB/Lync environments.

For an on-prem integration between SfB/Lync and Pexip Infinity, it is common to use an internal/enterprise Certificate Authority (CA) for requesting and creating certificates. However, for a public DMZ deployment of Pexip Infinity, a certificate from a public TLS/SSL certificate vendor/CA such as for instance Verisign, Comodo or GlobalSign is required.

We strongly recommend that all Pexip InfinityConferencing Node certificates should have both 'Server Authentication' and 'Client Authentication' Enhanced Key Usage properties.

This topic covers:

General information on managing certificates within Pexip Infinity can be found at Managing TLS and trusted CA certificates.

* Note that where this documentation refers to 'SfB/Lync', it represents both Microsoft Skype for Business and Lync unless stated otherwise.

Creating a certificate signing request (CSR)

The on-prem and public DMZ SfB/Lync integration guidelines both recommend that the same single certificate is installed on all Conferencing Nodes. This provides support for redundant Conferencing Node deployments and multiple SIP domains for SfB/Lync federation. Therefore, the certificate created for the Conferencing Nodes will typically need to contain multiple SANs (Subject Alternative Names). This type of certificate is also known as a UC certificate.

While this means that this single certificate will potentially contain a relatively high number of names, the administrator only has to manage a single SAN certificate across all Conferencing Node (unless multiple domain/subdomain support is required).

Wildcard TLS certificates are not supported in SIP or Microsoft Skype for Business / Lync environments (as per RFC 5922). If you are using SIP or Skype for Business / Lync, your Conferencing Nodes must not use wildcard TLS certificates.

You can use Pexip Infinity's inbuilt Certificate Signing Request (CSR) generator to assist in acquiring a server certificate from a Certificate Authority. Alternatively, you can use third-party tools such as OpenSSL toolkit.

Public DMZ environment requirements

When requesting certificates for Conferencing Nodes for public DMZ deployments:

• The Subject name (commonName attribute) should be set to the target hostname referenced by the _sipfederationtls._tcp SRV record (the pool name of the Conferencing Nodes).

  In our examples, if the DNS SRV record is:

  _sipfederationtls._tcp.vc.example.com. 86400 IN SRV 1 100 5061 px.vc.example.com.

  then the Subject name must be px.vc.example.com

• The Subject Alternative Name (altNames attribute) entries must include:

  • the target hostname referenced in the Subject name
  • the FQDNs of all of the public DMZ nodes that are involved in call signaling
  • the domain names that are used in any DNS SRV records that route calls to those Conferencing Nodes (e.g. vc.example.com from the example _sipfederationtls SRV record above).
• Assign the same certificate to all of the public DMZ nodes that are involved in call signaling.

See Assigning publicly-issued TLS server certificates to Conferencing Nodes for more information and examples for a public DMZ deployment.

On-prem environment requirements

When requesting certificates for Conferencing Nodes for on-prem deployments:

• The Subject name (commonName attribute) must be the Trusted Application Pool FQDN (such as confpool-eu.vc.example.com in our examples).
• The Subject Alternative Name (altNames attribute) entries must include the Trusted Application Pool FQDN (i.e. a repeat of the Subject name), plus the FQDNs of all of the nodes in the pool that are involved in signaling.
• Assign the same certificate to all of the enterprise nodes that are involved in call signaling.

See Assigning the certificate to Conferencing Nodes for more information and examples for an on-prem deployment.

Comparison of public DMZ and on-prem examples

When using Pexip Infinity's inbuilt CSR generator the examples below show the entries that would be required to match our example public DMZ deployment, and our example on-premises deployment (for the Europe-located pool of Pexip nodes):

See Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business / Lync and Certificate and DNS examples for an on-premises integration with Skype for Business / Lync for more information.

Adding additional nodes in the future

These SAN/UC certificates can normally be updated at any time (although usually for an additional fee) from most certificate vendors.

Thus, if for instance you need to add two additional nodes, you can create a new CSR containing the original altNames and the two additional altNames, submit the CSR to the certificate vendor, pay the additional fee (which is usually per SAN entry), get an updated SAN/UC certificate and then upload this new certificate to all nodes (the original certificate will be revoked and become unusable).

If you expect to deploy more nodes in the future, and have a predictable naming scheme for your nodes, you can also add extra altNames in anticipation of those future nodes.

Assigning a certificate to a Conferencing Node

In Pexip Infinity, certificates are managed from the Pexip Infinity Administrator interface under . You apply a certificate to a Conferencing Node by uploading the server certificate and associated private key and then assigning it to the Conferencing Nodes in question. The certificate should be in Base64-encoded X.509 (PEM) format.

The result of uploading and assigning our example public DMZ certificate and private key would look similar to this:

Certificates issued by intermediate CAs

In most cases, server certificates are issued by intermediate Certificate Authorities (as opposed to Root CAs). When this is the case, the chain of intermediate CA certificates must be installed on the Management Node to ensure that the certificate chain of trust is properly established when clients connect to a Conferencing Node over SIP TLS.

The intermediate CA certificates can be bundled/concatenated in a single text file and uploaded to the Management Node by going to and selecting Import. Whenever a Certificate Authority provides a server certificate issued through one or more intermediate CAs, the provider normally also provides this bundle of intermediate CA certificates as part of the process.

To identify whether or not a certificate has been issued by an intermediate CA, ensure that the certificate has a .cer file extension and open the certificate file on a Windows PC. Navigating to the Certification Path pane will display the CA structure of the certificate.

In the example below, the certificate for sip.pexipdemo.com has been issued by the intermediate CA Gandi Standard SSL CA, which is a subordinate CA for UTN-USERFirst-Hardware, which in turn is a subordinate CA for USERTrust, which is the root CA in this case:

In this particular case, UTN-USERFirst-Hardware and Gandi Standard SSL CA are the intermediate Certificate Authorities for the sip.pexipdemo.com certificate. This means that we would have to bundle together these two CA certificates in a text file and upload it using the trusted CAs facility on the Management Node in order to ensure proper certificate chain trust for the server certificates we install on the Conferencing Nodes.

Skype Certificate Error

Configuring the SIP TLS FQDN for a Conferencing Node

Skype For Business Settings Registry

When assigning a server certificate to a Conferencing Node, you must configure the SIP TLS FQDN for this Conferencing Node to an FQDN matching that of the certificate. The SIP TLS FQDN setting is configurable for each Conferencing Node, by going to and selecting the Conferencing Node in question.

The SIP TLS FQDN setting allows the administrator to set the DNS FQDN that a Conferencing Node will use when presenting its identity to connecting clients (by controlling which value the Conferencing Node will insert in its SIP contact header). Each Conferencing Node must have a unique SIP TLS FQDN.

Using our public DMZ example, when assigning a Conferencing Node a common certificate issued to px.vc.example.com but where that certificate contains each Conferencing Node's FQDN as one of the certificate's altNames, you would then normally also configure the node's hostname (px01.vc.example.com in this example) as the SIP TLS FQDN for this Conferencing Node (and px01.vc.example.com would also be the DNS A-record pointing to the publicly-reachable IP address of the Conferencing Node in question):

In our on-premises example, the node with a hostname of conf01.vc.example.com would have its SIP TLS FQDN also set to conf01.vc.example.com, and so on for the other Conferencing Nodes.

Configuring Windows Server Manager to use a certificate template with client and server capabilities

If a Conferencing Node connects with a video network infrastructure device that performs a TLS verification process, the server certificate on the Conferencing Node needs Client Authentication capabilities. By default, the 'Web Server' certificate template used by the Microsoft Certification Authority tool in Active Directory Certificate Services (AD CS) creates a certificate with Server Authentication capabilities only. This section describes how to configure Windows Server Manager to use a certificate template with client and server capabilities.

To set up a certificate template with Server and Client Authentication (using Windows Server Manager 2016):

1. In Windows (server edition), launch .
2. Launch the tool.
3. Expand the navigation tree for your Certification Authority and select .

4. Right-click on and select to open the .

5. Create a new template based on the existing template:

   1. Right-click on (in the list of templates) and select .

   2. On the tab, enter the Template display name and Template name for your new template, for example 'Web Client and Server' and 'WebClientServer' respectively.
   3. On the tab, select and select .

   4. Add Client Authentication to the set of application policies:

      1. Select .
      2. Select Client Authentication and select .
      3. Select .
   5. Select to complete the addition of the new template.
6. You can now close down the Certificate Templates Console.

7. Add the new template to your Certificate Authority:

   1. From the tool, expand the navigation tree for your Certification Authority, right-click on and select New > Certificate Template to Issue.

   2. Select your new Web Client and Server template and select .

The new Web Client and Server template can now be used when submitting a certificate request to that Microsoft Certification Authority.

Note that all CSRs generated via Pexip Infinity's inbuilt CSR generator always request client certificate and server certificate capabilities.