Showing posts with label certificates. Show all posts
Showing posts with label certificates. Show all posts

Managing SSL certificates may be getting that much more difficult

Wednesday, August 14, 2019
Remember when you used to be able to get an SSL certificate that lasted 3-5 years? Now you can only get one that lasts 2 years, and a change proposed by Google would reduce the maximum validity period to just 13 months beginning March 2020. This would be a global change to the industry, impacting all certificate authorities.

Read this important update from Digicert:


IMPORTANT UPDATE
Dear Security Professional,

We are reaching out to you regarding an important proposal raised recently at the CA/Browser Forum that could impact the products you are using.

What’s happening?
Google proposed a change that, if the ballot passes, will reduce the validity period of certificates from the current maximum of two years to 13 months. The proposed ballot was endorsed by Apple and another CA, making the ballot eligible for voting. If the ballot passes at the CA/Browser Forum, the change in requirements will go into effect in March 2020. Any certificates issued after the effective date would need to comply with the shortened validity period requirements. Even if the ballot fails, the browsers sponsoring the ballot could unilaterally implement this requirement in their root program and make compliance required for certificates issued by trusted CAs in their root stores.

This change is a follow up on Google’s previous initiative to reduce lifetimes from three to two years https://www.digicert.com/blog/3-year-certificates-eliminated-industry-wide-change/) in 2018.

Who is impacted?
The changes proposed by Google would impact all publicly trusted TLS certificate users, regardless of which certificate authority issues the certificate. If the ballot passes, all publicly trusted certificates issued or re-issued after March 2020 would have a maximum validity of 13 months. Customers using certificates with validity periods longer than 13 months are encouraged to review their systems and evaluate how the proposed changes might impact their deployment and use of certificates.

Please note that all TLS certificates issued prior to March 2020 with a validity period longer than 13 months will remain functional. This ballot does not affect non-TLS certificates, including code signing, private TLS, client certificates, etc. There will be no need to revoke any certificates as a result of this ballot.

This would be a global change to the industry, impacting all certificate authorities.

DigiCert’s position
DigiCert believes industry-wide changes should be made only after measuring whether the changes in security are sufficiently balanced with the impact on end users. In this case, we feel that further shortening certificate lifetimes, especially absent reasonable timelines for companies to prepare, would have the opposite effect in causing significant pain to customers and possibly leading to some human-caused errors as they scramble to adjust.

We believe the goal of improving certificate security is better served by allowing more time for companies to continue their growing use of automation and to prepare for these changes. DigiCert would like to continue the conversation and gather customer input before this issue is brought to a ballot. We think this discussion should include a timeline that allows for companies to properly plan for shorter lifetimes.

Regardless of the outcome of this ballot, we stand ready to help our customers. DigiCert’s focus and deployment of discovery and automation tools make sure our systems are fully capable of helping our customers meet changes that may arise in industry standards, including shortening lifecycles. In fact, DigiCert currently offers certificate lifetimes as short as eight hours for customers who want that option. Having said that, our ability to help our customers with these changes doesn’t mitigate all the potential impact that a rushed implementation would have on the industry.

What to do
The CA/Browser Forum makes changes to standards as security issues evolve. To remain compliant with these changes, organizations with large amounts of certificates should consider sophisticated automation tools to help manage certificate inventories and ease certificate deployment. At DigiCert, we are focused on simplifying the certificate management process and developing new tools for automating certificate use. Customers worldwide use DigiCert to automate their process using our Lemur plug-ins, REST APIs, SCEP and EST services, and ACME service. Combining ACME with the automated scanning service in CertCentral allows TLS customers to easily scan their entire environment, find certificates that require replacement, and deploy up-to-date technology.

DigiCert will continue to keep you apprised of CA/B Forum activities. Please read our position to the industry in this new blog: https://www.digicert.com/blog/how-reduced-tls-ssl-certificate-lifetimes-to-one-year-would-affect-you/

Be heard
The CA/Browser Forum accepts comments from outside participants; however, all discussions are public. You have two choices: you can submit your comments to DigiCert through this survey, which we plan to summarize and provide to the CA/B Forum or you can join the CA/B Forum as an Interested Party, which will allow posting of your comments directly to the Forum mailing list. See https://cabforum.org/working-groups/ (bottom of page).

We are eager to share information with the browsers about the impact these changes may have on customers. We look forward to providing this information and representing your interests in the Forum and security world.

Read more ...

Fix for Certificate Error in Chrome - NET::ERR_CERT_COMMON_NAME_INVALID

Tuesday, June 6, 2017
It amuses me when Google dictates security policy.

Beginning with Chrome 58, the Chrome browser no longer uses the Common Name (CN) field to validate an SSL certificate. Instead, it only uses the Subject Alternative Name field.

This is in violation of RFC 2828 which states,
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
So someone in Google security said, "Hey! If RFC 2828 says the Common Name is deprecated, we should start making Chrome ONLY use the Subject Alternative Name! Existing practice, be damned." Never mind the fact that the RFC was written May 2000, and every other browser and app on the planet uses the Common Name field for single-name certificates.

Therein lies the problem. Most single name certificates and some wildcard certificates only have a Common Name and don't have use Subject Alternative Names. This causes Chrome 58 and later to display the following (incorrect) error. It even goes so far as to blame it on a server misconfiguration.

NET::ERR_CERT_COMMON_NAME_INVALID [missing_subjectAltName]
This same website (in this case, OWA) displays properly in all other browsers. If we look at the certificate, we see this is a wildcard cert for *.contoso.com issued by an internal certification authority (CA). The Details tab shows there is no Subject Alternative Name field for this cert.

Wildcard certificate details with only a Common Name (CN) field

To fix the error for your Chrome users, you'll need to regenerate the certificate to include a Subject Alternative Name. Here's how to do that using the Certificates MMC when you have an internal Certification Authority (CA).

From the web server, open MMC and add the Certificates snap-in, managing the Computer account. Then expand Certificates (Local Computer) > Personal > Certificates.

Right-click Certificates > All Tasks > Request New Certificate.

Choose Active Directory Enrollment Policy to use your existing internal CA.

Select the Web Server certificate template and click the link below it to enter more information.

Add the Common Name for the Subject Name, and the DNS name for the Alternative Name. They can be the same value. Chrome 58 and later only uses the DNS alternative name.

Enter a Friendly Name on the General tab.

Optionally, make the private key exportable on the Private Key tab and click OK.

Click Enroll to generate the new cert from the CA and install it on the web server.

The certificate will be installed. Click Details to view the new certificate.

On the Details tab we see the Subject Alternative Name is on the new cert.

Now you'll either need to configure IIS to use the new certificate (Web Site - Bindings) or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.

Read more ...

Is Your Organization Still Using SHA-1 Certificates?

Friday, February 24, 2017
Google just publicly cracked the SHA-1 algorithm, officially rendering SSL certificates using this encryption algorithm insecure from man-in-the-middle attacks.

The National Institute of Standards and Technology (NIST) mathematically predicted this would happen about this time back in January 2011. See NIST Special Publication 800-131A Revision 1: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. Based on this recommendation, Google Chrome started warning users when they visited an SSL secured website that uses SHA-1 beginning November 2014.

Google Chrome SHA1 Notifications Gradually Ramped Up Over Time
Microsoft stated their SHA1 Deprecation Policy back in November 12, 2013, but it has since been removed. It originally said that that Windows will stop accepting SHA-1 end-entity certificates by January 1, 2017, and will stop accepting SHA-1 code signing certificates without timestamps after January 1, 2016. They updated their SHA-1 deprecation timeline to mid-2017 "to ensure compliance in all configurations and scenarios for Microsoft Edge and Internet Explorer 11."

Clearly, Google was more than happy to prove NIST's prediction right by announcing the first public SHA1 collision on February 23, 2017. Microsoft wrote a response the same day, but their timeline to remove SHA1 functionality from Windows remains mid-2017.

So who's at risk and what can be done about it?

Companies that use SSL-secured websites should check them to ensure they are not using the SHA-1 algorithm on any certificate. Root certificates are not affected by this, but best practice is to upgrade all Certificate Authorities (CA) to use the SHA256 algorithm. Nothing says bad press like a security warning or breach.

EXPTA Consulting provides PKI infrastructure services and can help install, reconfigure, or upgrade your existing PKI infrastructure securely and safely.

Users should run the latest versions of browsers. They should also be educated about browser security warnings, what they mean, and how to handle them.

Here are the current warnings users will see when visiting an SSL website using the SHA-1 algorithm from three popular browsers on Windows 10:

SHA1 Website in Chrome

SHA1 Website in Edge

SHA1 Website in Internet Explorer 11



Read more ...

How to Perform HTTP -> HTTPS Redirection in a Single Exchange Server Environment

Tuesday, August 30, 2016
HTTP to HTTPS redirection in Outlook Web App is a user convenience that many admins consider a necessity. It automatically redirects the user's browser to https://mail.contoso.com/owa if they enter http://mail.contoso.com, or simply mail.contoso.com. Without redirection, the user will get an HTTP 403 Forbidden error page, like the one below.


This happens because the SSL settings on the Default Web Site and all subdirectories are configured to require SSL.

In multi-server environments where load balancers are used, HTTP -> HTTPS redirection is normally performed on the load balancer. Most load balancers, such as KEMP or F5, automatically configure it when you deploy one of their Exchange server templates.


In single Exchange environments without a load balancer, you must configure redirection directly on the server itself. The steps below explain how to do this. I've used this method since Exchange 2007 and it works perfectly 100% of the time. Other methods I've seen on the Internet sometimes cause routing errors.

  • Open Internet Information Services (IIS) Manager on the Exchange 2016 or Exchange client access server and navigate to Sites > Default Web Site.
  • Double-click Error Pages and add a new custom error page for status code 403.4 that responds with a 302 redirect to https://mail.contoso.com/owa.



  • Special note for Exchange 2016 - The Exchange team did a little number in the web.config file on Exchange servers to "improve performance", but it removes the custom error page behavior. So you'll need to do the following:
    • Open the C:\inetpub\wwwroot\web.config file in Notepad.
    • Remove the following line, and then save and close Notepad:
<remove name="CustomErrorModule" />


Note that this web.config edit will need to be made after every Exchange 2016 CU installation since setup overwrites this file.

That will handle the HTTP 403.4 - Forbidden: SSL is required error behavior in the browser. All that's left is to handle what happens when a user enters https://mail.contoso.com.

  • Using Notepad, create a web page called default.htm in the C:\inetpub\wwwroot folder of the Exchange 2016 or client access server. Add the following three lines:

<html>
<meta http-equiv="REFRESH" content="0;url=/owa">
</html>
  • Save and close Notepad, and then test redirection.

Read more ...

New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

Friday, July 22, 2016
Set-AutodiscoverSCP.ps1
I just published version 2.0 of my Set-Autodiscover.ps1 script to the TechNet Gallery. This is a complete rewrite of the old script and includes the following new features:
  • Made setting the new values easier by cloning an existing server
  • Now also configures Outlook Anywhere and all Exchange virtual directory internal and external URLs
  • Revised verbiage and use *-ClientAccessService cmdlets for Exchange 2016
  • Added -Verbose output to display the values we're configuring
  • Improved overall display output
These changes are intended to make the script more powerful and easier to use.



How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured in Active Directory when the Front-End Client Access role is installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the self-signed Exchange certificate installed by setup is not trusted. If the new server is Internet-facing, ActiveSync clients can also get security warnings on their mobile device.


Read Exchange Active Directory Deployment Site for more information about this behavior.

I wrote a script, Set-AutodiscoverSCP.ps1 (available on the TechNet Gallery), that automatically updates the SCP, Outlook Anywhere FQDNs, and all the virtual directory internal/external URLs for the server your specify to match the values currently configured on another server you specify as soon as the new server is detected in AD. It continually polls Active Directory until it finds the new SCP value and sets the new values. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:
Set-AutodiscoverSCP.ps1 [-Server] <String> [-ServerToClone] <String> [[-DomainController] <String>] [<CommonParameters>]
Two examples of usage:
PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01
Example #1 continually queries the current configuration domain controller until it finds an SCP for server EXCH02 and then sets it to match the SCP of EXCH01. It also configures Outlook Anywhere and the internal/external virtual directory URLs to match those found on EXCH01.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01 -DomainController dc03
Example #2 is almost the same as the command in the previous example, except it continually queries DC03 for the SCP record and configures it on that domain controller. This is useful when configuring a new Exchange server in a different Active Directory site.

The script is designed to be run during installation. Normally, you would run this script from an existing Exchange server of the same version while the new server is being installed.

You can also run the script directly from the server that is being installed. This is useful when you're installing the first Exchange 2013/2016 server in a 2010 environment. You can start running the script on the new server when the Client Access Front End Service is being installed. The caveat is that setup restarts IIS and web services several times during setup, causing the script to possibly stall during configuration of the virtual directories. If that happens, simply CTRL-C to quit the script and run it again.

I've included error handling for the following conditions:

  1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
  2. The script checks that the server, server to clone, and the domain controller (if specified) are pingable. If the servers cannot be pinged, the script will terminate.
  3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script again on the TechNet Gallery as needed.

Read more ...

Set-AutodiscoverSCP.ps1 script is now on the TechNet Gallery

Thursday, October 8, 2015
UPDATE: This script has been significantly updated and enhanced. Please read New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured when the Front-End Client Access role or components are installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the server FQDN is not on the Exchange certificate and it is not trusted.

 

Older versions of Outlook (~Outlook 2010 RTM and earlier) used to use the oldest SCP value in the AD site, but newer versions use the newest SCP for foreground and background Autodiscover requests, causing these errors.

I wrote a script, Set-AutodiscoverSCP.ps1 (available in the TechNet Gallery), that automatically updates the SCP for the server your specify to the value you provide as soon as the new SCP for that server is detected in AD. It will continually poll Active Directory until it finds the new SCP value and sets it to the one you specify. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:
Set-AutodiscoverSCP.ps1 [-Server] <String> [-NewSCP] <String> [[-DomainController] <String>] [<CommonParameters>]

Two examples of usage:
PS C:\>Set-AutodiscoverSCP.ps1 -Server exch01 -NewSCP https://autodiscover.contoso.com/autodiscover/autodiscover.xml
Example #1 continually queries the local Active Directory domain until it finds an SCP for server EXCH01 and then sets that SCP to https://autodiscover.contoso.com/autodiscover/autodiscover.xml.


PS C:\>Set-AutodiscoverSCP.ps1 -Server exch01.contoso.local -NewSCP https://autodiscover.contoso.com/autodiscover/autodiscover.xml -DomainController dc03.contoso.local
Example #2 is almost the same as the command in the previous example, except it continually queries DC03.CONTOSO.LOCAL for the SCP record and configures it on that domain controller. This is useful when configuring the SCP for a new Exchange server in a different Active Directory site.


I’ve included error handling for the following conditions:
  1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
  2. The script checks that the server you want to configure is pingable. If the server cannot be pinged, the script will terminate.
  3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script on the TechNet Gallery as needed.

Read more ...

Is Your Organization Using SHA-1 SSL Certificates?

Tuesday, November 11, 2014

I just published an article on Windows IT Pro about Microsoft's decision to block Windows from accepting SHA-1 SSL certificates. This has important ramifications for your users and your IT environment. Don't be caught unaware.

Read "Is Your Organization Using SHA-1 SSL Certificates?" on Windows IT Pro here.

Read more ...

How to Enable Notifications for Pending Certificate Requests

Thursday, July 12, 2012
You can configure a Windows Certification Authority certificate template to require CA certificate manager approval, as shown below. 


With this configuration autoenrollment is disabled and the CA Manager must approve the certificate request before the certificate is issued.

Normally, CA managers need to check in periodically to see if there are any pending requests to approve or decline.  This article discusses how to enable email notifications when a certificate request is generated that requires approval.

First, my best practice is to create a mail-enabled security group in Active Directory called CA Managers.  Add the appropriate user objects to this group and assign that group Issue and Manage Certificates and Manage CA rights on the Certification Authority, as shown below:


Now we need to configure event logging for Certificate Services for verbose logging.  Run the following command from a CMD prompt on the CA:
certutil -setreg ca\loglevel 4
You must restart the Active Directory Certificate Services service (CertSvc) to affect the logging level change.  The CA will now log event ID 54 from source CertificationAuthority in the Application event log whenever a certificate request is generated.  For example,

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          7/12/2012 8:16:29 AM
Event ID:      54
Task Category: None
Level:         Information
Keywords:      Classic
User:          SYSTEM
Computer:      dc1.companyabc.com
Description:
Active Directory Certificate Services left request 51 pending in the queue for C=US, S=CA, L=Pacifica, O=Expta, OU=IT, CN=Admin,
E=admin@companyabc.com.  Additional information: Taken Under Submission


All we need to do now is create an Event trigger on this event.  The easiest way to do that is to create a certificate request so we can attach a task to the event it logs.  Once you create the certificate request, find the event ID 54 in the Application event log on the CA.  Right-click the event and select Attach Task To This Event.



This will open the Create Basic Task Wizard which we will use to configure the email notification.  Give the task a name and description, as shown below, and click Next:



The specific event details are prepopulated from the event we selected.  Click Next:



Select Send an e-mail from the Actions list and click Next:



Complete the details for the email, as shown below.  Enter the valid SMTP address for the CA Managers group (created above) in the To: field.  I include the URL to the CA approval page in the message text for easy access by the CA Managers.  Ensure that your CA server is allowed to send SMTP email to the SMTP server you designate in the wizard.  I use Telnet to test that.



Review the summary.  Select the check box to Open the Properties dialog for this task when I click Finish and then click Finish.


By default this task will only run when the user who created it is logged on.  Change the task to run under the NT Authority\SYSTEM account by clicking the Change User or Group button and entering the local SYSTEM account.  This will also configure the task to run whether the user is logged on or not.  Now click OK to complete the task.


You can view, change or delete this task in the Event Viewer Tasks in the Task Scheduler Library.

Test the new configuration by generating another certificate request.  All members of the CA Managers group should receive an email indicating that a new certificate request is pending, along with a link to the CA's web approval page, as shown below:


 

Read more ...

How to recreate a lost private key for a certificate

Friday, May 13, 2011
Occasionally a certificate will become corrupt or is installed without a properly generated private key.  Such is the case with a bare CER certificate file.  When this happens it will often no longer function with Exchange, IIS, or other web servers.
Here is how to recreate the private key for an installed certificate.
  • Open the Certificates management console (Start > Run > MMC > Add/Remove Snap-in > Certificates > Computer Account > Local Computer)
  • Expand Certificates (Local Computer) > Personal > Certificates
  • View the properties of the certificate you want to create a private key for.  On the Details tab, click Serial number.
  • Copy the serial number, as shown below, to the clipboard:
  • From an elevated CMD prompt, run the following command:

The output will look something like this, showing that the repairstore command completed successfully:


You will now see a small gold key in the icon for the certificate, indicating that you have the private key.  You will also see the message, "You have a private key that corresponds to this certificate" on the bottom of the properties of the certificate.


certutil -repairstore my "<Serial Number>"
Read more ...

How to Easily Check for a Windows Enterprise CA

Friday, April 29, 2011
I work with a lot of different clients and often need to generate private certificates for applications, such as Exchange, Lync Server, and System Center.  I'm often surprised that clients aren't aware if they even have a certificate authority server in their domain and if so, what it's name is.

Here's a simple way to check for an enterprise CA in a Windows domain.  Run the following command from a CMD prompt:
certutil -config - -ping

Notice the extra dash "-" between the -config and -ping switches.

If there is an enterprise CA published in Active Directory, you will see a pop-up box asking you to choose the CA to ping, as shown below:


Notice that CA name and the computer that hosts it are displayed.  Once you select the certification authority and click OK, certutil will ping the server to make sure that it's online and functioning, as shown below:

Certutil successfully pinged the CA
If certutil is enable to locate and Enterprise CA in the domain, it will display an error message indicating that no active Certification Authorities were found:

Certutil was unable to locate an Enterprise CA in the domain
Read more ...

Replacing a Federation Trust Certificate When the Original Certificate is Missing

Friday, October 22, 2010
Exchange 2010 federation allows organizations to share calendar free/busy information (also known as calendar availability) and contact information with external recipients, vendors, partners, and customers.  This is accomplished by creating a trust with Microsoft's Federation Gateway.  This cloud-based service offered by Microsoft acts as the trust broker between your on-premises Exchange 2010 organization and other federated Exchange 2010 organizations.  For more information about Exchange federation, see Understanding Federation.

To configure federation you install an Exchange certificate, enable the certificate for Federation, and create a federation trust with Microsoft Federation Gateway.  Eventually you will need to replace this certificate, either for business reasons or when the certificate expires.  The usual way of doing this is to install a new Exchange certificate and configure it as the "Next Certificate" in the Manage Federation Certificate wizard, as shown below.


When you're ready to replace the current federation certificate you simply run the Manage Federation wizard, select the "Roll certificate to make the next certificate as the current certificate" check box, and complete the wizard.  What was the Next Certificate becomes the Current Certificate, and the Current Certificate becomes the Previous Certificate.

I ran into an interesting issue where the process above did not work.  The customer deleted the Current Certificate from the computer's local certificate store, rather than roll the Next Certificate into the current certificate's place.  This causes the Manage Federation wizard t break because it can't locate the Current Certificate.  I was also unable to use the Set-FederationTrust cmdlet in EMS - it would give the same error:
[PS] C:\>Set-FederationTrust -Identity "Microsoft Federation Gateway" -PublishFederationCertificate
Federation certificate with the thumbprint "29FD8FFF241A4317ABAAF326226BC209F682C2F3" cannot be found.
    + CategoryInfo          : InvalidResult: (:) [Set-FederationTrust], FederationCertificateInvalidException
    + FullyQualifiedErrorId : 906B427C,Microsoft.Exchange.Management.SystemConfigurationTasks.SetFederationTrust
To fix this, you'll need to do it using ADSIEdit.
  • Log into a computer with administrator rights and run ADSIEdit.msc
  • Connect to the Configuration naming context
  • Navigate to CN=Federation Trusts,CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
  • Right-click CN=Microsoft Federation Gateway in the work pane and select Properties
  • Edit the msExchFedOrgNextCertificate property (which contains the thumbprint of the Next Certificate) and copy the entire value.  Close the msExchFedOrgNextCertificate property.
  • Edit the msExchFedOrgPrivCertificate property (which contains the thumbprint of the Current Certificate, which was removed) and paste the value.  Click OK to set the value.
  • Wait for the change to replicate throughout your AD infrastructure.
  • From the Exchange Management Console, run the Manage Federation Wizard.  You will now notice that the Current Certificate and the Next Certificate are the same.
  • Check Roll certificate to make the next certificate as the current certificate and complete the wizard.
Don't forget to test your configuration with the Test-Federation cmdlet.
Read more ...

How to Create Certificates with a Longer Validity Period

Friday, August 27, 2010
So, you have your own Windows Certificate of Authority (CA) server and you want to create some new certificates that are valid longer than the default certificate templates.  You duplicate the User Certificate, and set the validity period to 5 years.  You issue a new user certificate using the new template and discover that the certificate expires two years from today.  What's up with that?

The validity period of any certificate generated by a Windows CA is the lesser of these three values:
  • The remaining lifetime of the root CA server 
  • The value specified in the certificate template
  • The value specified in the CA server registry (default is 2 years)
So even if you set the certificate template validity period to 10 years, certificates issued using this template will be valid for a maximum of two years with the CA's default settings.

Increasing the CA Lifetime
Most root CAs are typically valid for 5 years. To increase the lifetime of the root CA, create or edit a text file in %SYSTEMROOT% called CAPolicy.inf with the following text:
[Version]
Signature=”$Windows NT$”


[certsrv_server]
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
Adjust the values above as needed, save the file, and restart the CertSrv service. Then renew the CA Certificate using the same public and private key pair.

Warning: If you generate a new public and private key pair you will need to reissue all your old certificates, so don't do it unless that is your intent.

Setting the Maximum Validity Period in the Registry
The default certificate validity period configured in the CA's registry is 2 years. To view the current registry value, run the following commands from a CMD prompt on the CA:
certutil -getreg ca\ValidityPeriod
certutil -getreg ca\ValidityPeriodUnits
To configure the registry value to 5 years, run the following command from a CMD prompt on the CA:
certutil -setreg ca\ValidityPeriodUnits 5
Adjust the value above, as needed. Then restart the CertSvc service to affect the changes.
Read more ...