I have a small test network that includes Win2k8 R2 machines, an Enterprise CA server and an Exchange 2010 SP1 RU1 CAS server. I would like to issue a certificate for Exchange from the CA.
As the first step, I created the certificate request, which (according to OpenSSL) contains the following info:
As the second step, I would like to submit this request to the CA, but I get the following message:
What would be the best way to get this working?
How should I generate the same request from Exchange to include the info on which certificate to use?
How should I convince the CA to issue the certificate, even if the request doesn't match a certificate template?
(I'm actually interested in the answer to all three questions to learn more about both Exchange and the CA services.)
maweeras
2,63622 gold badges1313 silver badges2323 bronze badges
ZizzencsZizzencs
67911 gold badge99 silver badges2222 bronze badges
1 Answer
Please use the wizard that Exchange 2010 so helpfully provides for you - it's much easier.
It's in the Exchange Management Console under Server Configuration. In the Action Pane, choose the New Exchange Certificate wizard.
Fill in the required info, submit the generated file to your Enterprise CA using the Web Server template, then import the generated certificate back into Exchange using the wizard.
You might find this video helpful.
Ben PilbrowBen Pilbrow
11.4k44 gold badges3232 silver badges5757 bronze badges
Not the answer you're looking for? Browse other questions tagged exchange-2010certificate-authorityad-certificate-services or ask your own question.
If you need to install an internal certificate server to create certificates for Exchange 2010 , remember to add the SAN certificates support to the certificate server as it is needed by the exchange server and will solve the problem of disappearing certificates after importing it to Exchange 2010.
Install the Certificate Server. In Windows 2008 from Server Manager > Roles > Add New Role.
On the next Screen (Before you begin) click Next, then on the (Server Roles) screen, select “Active Directory Certificate Services”
Click Next, Next. On the “Select Role Services Screen”, Select “Certificate Authority” and “Certification Authority Web Enrollment”.
If your server doesn’t have IIS installed, it will tell you that it will install it for you. Click “Add Required Role Services”, Then click Next
On the Setup Type, select “Enterprise”, click Next
On the “Specify CA Type”, select “Root CA”, Click Next
On “Setup Private Key”, Select “Create a new private key”, Click Next
On “Configure Cryptography for CA”, leave the default options, Click Next
On “Configure CA Name”, Leave the defaults, Click Next
On the “Validity Period” screen, select how many years before the certificate is expired, or you can leave the defaults “5 Years”, Then Click Next
On the Certificate Database Location, leave the defaults, then click Next.
On IIS installation, Click Next
On the Roles screen, you can add more services in IIS or leave the defaults and click Next
On the “Confirmation Page”, Setup will warn you that the Domain name and setting can not be changed later after you install Certificate Authority. If you do not intend to change your Domain or Settings later, Click Install.
Setup will begin installation
When installation is completed, Click Close
Then you will need to add SAN certificates support to your Certificate Authority. SAN stands for (Subject Alternate names). So that the certificate can be for more than one server name, e.g. Mail.company.com, Exch.company.com, Exchange01, …….
To ADD SAN support, Open the Command Prompt, then paste the following command:
Certutil –setreg policyEditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2
Then Restart the Certificate Service by issuing the following two commands in the command prompt:
net stop certsvc
net start certsvc
Now go to your Exchange Server, Open the Management Console then from Server Configuration, Click on “New Exchange Certificate”
Enter A name for your Certificate, then click Next
Leave the ” Enable Wildcard Certificate ” un-checked, then click Next
Select the services that exchange will handle. This is to determine the names that will be added to the certificate
Then it will display the domain names that will be added to the certificate. In this example I assumes that the following names for the Exchange server:
Server Name: EXCHANGE01
Internet name: mail.company.com
Intranet name: Exchange01.company.com
You can add additional domain names as well by clicking on the green Plus sign (Add…). When finished, click Next.
Enter Organization and Location Data. Also Specify where the Certificate Request will be saved (Here in C:)
Click Next, Then Click New
Exchange will start creating the Certificate Request
When Completed , Click Finish
Open CA web page using an Internet Browser, For Example http://Localhost/CertSrv if you are opening from the CA itself, Then click on ” Request a Certificate ” Link
Then Click on Advanced Certificate Request
Then Click on ” Submit a Certificate Request ”
Open the Certificate Request file you created in Exchange With Notepad (in our example here was C:Cert1.req) Select all Text
Paste the text into the webpage, and select ” Web Server ” from th Certificate Template list, Then Click Submit.
Select Base 64 Encoded, then click on Download Certificate Chain. Save the certificate to your loacl Disk.
On The Exchange Server:
Click Start, type: MMC, Then press Enter
An Empty Console opens, From File Menu select: Add – Remove Snap-in
Add Certificates Snap-in, Select Computer Account Select Local Computer, then Click Finish, Then Click OK
Right-Click on the Certificate in the Trusted Root, Then Import the Created Certificate which we downloaded from the CA
From the Exchange Management Console, Click Server Configuration, the Exchange certificate we requested, then Click on Complete Pending Request
Select the Certificate we downloaded from the CA, then Click Complete
Right click on the Certificate, select Assign services to certificate
Importing Certificates into Computers, For computers in your domain, follow these steps:
On your domain controller, start Group Policy Management Console (Start menu, type ” gpmc.msc “, Press Enter).
Either create a new group policy or use the Default Domain Policy to deploy it to every system.
Right-click the policy of your choice and select Edit… go to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies
Right-click Trusted Root Certification Authorities, and choose Import…
Use the import wizard browse over to your root certificate we have created earlier.
If have computersnot members in the domain, you can import the certificates manually, for Windows 7:
Open Certificate Manager by clicking the Start button , type ” certmgr.msc ” into the Search box, and then pressing ENTER.
Trusted Root Certification Authorities > Right Click Certificates Folder, Select Import.
Import the Certificate we have created earlier.
I hope I could gave you a brief idea on setting up internal CA to issue certificates for your Exchange server.
Advertisements
Scenario:
Customer had hired a Consultant to originally setup their Exchange 2007 environment and now their Certificate had expired. Was originally setup to use their 2008 Enterprise CA so customer not only did not know how to generate the request from within Exchange but also did not know how to submit it to their own CA (I know).
Now with a 2003 CA I would just generate the certificate request from within Exchange Management Shell then Browse to http://CA-Name/CertSRV> Click Request a Certificate>Advanced Certificate Request>Submit a Certificate Request by Using a Base-64….>Then select “Web Server” from the Certificate Template drop-down (Figure 1).
However, on a 2008 CA you do not have the option for Web Server (Figure 2)
This obviously makes it difficult to use the old familiar web-based interface to request your certificate. I believe these additional templates were removed from /CertSRV by default due to security reasons but I have yet to confirm.
Resolution:
So in this case I just needed to generate the certificate request on 2007, copy the .req file to my CA, and use the certreq.exe utility on the CA to process the request. The commands for the request are as follows:
Certreq.exe –submit –attrib “CertificateTemplate:webserver” C:RequestFile.req NewCertName.cer
Depending on the settings of your CA this request may be auto approved (in which case the .cer file will be located in your current working directory in Command-Prompt; or just specify a path in the command) or you may need to approve it. You can do this either by launching the Certificate Authority MMC snap-in and going to “Pending Requests” or using the following command:
Certreq.exe –accept NewCertName.cer
Once you get the cert file just import it using Exchange Management Shell (if 2007; I usually recommend the GUI Wizard in 2010).
References:
If you choose to use the command line method on a 2003 CA then you may have to go through the following article
In searching to see if anyone else had published these steps I ran across the blog of Jeff Schertz. I’ve been to his blog before and always find great content. Here’s the referenced post but check out some of his other great articles; specifically for Lync.
Edit: Check this post if you receive a “Certificate Not Issued (Incomplete)” message via command prompt.
Advertisements
-->
This cmdlet is available only in on-premises Exchange.
Use the New-ExchangeCertificate cmdlet to create and renew self-signed certificates, and to create certificate requests (also known as certificate signing requests or CSRs) for new certificates and certificate renewals from a certification authority (CA). For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax (https://technet.microsoft.com/library/bb123552.aspx). SyntaxDescription
Exchange uses certificates for SSL and TLS encryption.
There are many factors to consider when you configure certificates for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) services. You need to understand how these factors might affect your overall configuration. For more information, see Digital certificates and encryption in Exchange 2016.
Secure Sockets Layer (SSL) is being replaced by Transport Layer Security (TLS) as the protocol that's used to encrypt data sent between computer systems. They're so closely related that the terms 'SSL' and 'TLS' (without versions) are often used interchangeably. Because of this similarity, references to 'SSL' in Exchange topics, the Exchange admin center, and the Exchange Management Shell have often been used to encompass both the SSL and TLS protocols. Typically, 'SSL' refers to the actual SSL protocol only when a version is also provided (for example, SSL 3.0). To find out why you should disable the SSL protocol and switch to TLS, check out Protecting you against the SSL 3.0 vulnerability (https://blogs.office.com/2014/10/29/protecting-ssl-3-0-vulnerability/).
You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet (https://technet.microsoft.com/library/mt432940.aspx).
Examples
-------------------------- Example 1 --------------------------
This example creates a self-signed certificate with the following settings:
The Subject value is CN=<ServerName> (for example, CN=Mailbox01).
The Domains (subject alternative names) value is <ServerName>, <ServerFQDN> (for example, Mailbox01,Mailbox01.contoso.com).
The Services value is IMAP,POP,SMTP
The Services value SMTP grants the Network Services local security group read access to the certificate's private key.
The Services value SMTP and the Subject value that contains the server name publishes the certificate to Active Directory so that Exchange direct trust can validate the authenticity of the server for mutual TLS.
If you don't want this certificate to replace the existing self-signed certificate that was created during Exchange setup, be sure to select 'No' in the prompt that asks you overwrite the existing default SMTP certificate.
-------------------------- Example 2 --------------------------
This example creates a new certificate request for a certification authority that has the following settings:
The request is Base64 encoded.
The output is displayed onscreen and is also written to the text file C:Cert Requestswoodgrovebank.req.
The Subject value is c=US,o=Woodgrove Bank,cn=mail.woodgrovebank.com
The Domains (subject alternative names) value contains the additional valuesautodiscover.woodgrovebank.com,mail.fabrikam.com, and autodiscover.fabrikam.com.
After you create the certificate request, you send the output to the CA. After you receive the certificate from the CA, you install the certificate by using the Import-ExchangeCertificate cmdlet, and you assign the certificate to Exchange services by using the Enable-ExchangeCertificate cmdlet.
If the CA requires the certificate request in a file that's encoded by DER, use the BinaryEncoding switch.
-------------------------- Example 3 --------------------------
This example renewsthe existing self-signed certificate that has the thumbprint value c4248cd7065c87cb942d60f7293feb7d533a4afc. You can find the thumbprint value by using the Get-ExchangeCertificate cmdlet. Setting the PrivateKeyExportable parameter to the value $true allows the renewed self-signed certificate to be exported from the server (and imported on other servers).
-------------------------- Example 4 --------------------------
This example creates a request to renew an existing certificate that was issued by a certification authority. The certificate request has the following settings:
The thumbprint value of the existing certificate is 8A141F7F2BBA8041973399723BD2598D2ED2D831. You can find the thumbprint value by using the Get-ExchangeCertificate cmdlet.
The request is Base64 encoded.
The output is displayed onscreen and is also written to the text file C:Cert Requestsfabrikam_renewal.req.
After you create the certificate renewal request, you send the output to the CA. After you receive the renewed certificate from the CA, you install the certificate by using the Import-ExchangeCertificate cmdlet.
-------------------------- Example 5 --------------------------
This example shows how to renew a self-signed certificate with a specific thumbprint value. You can obtain the thumbprint value in one of two ways.
Select the certificate in the Exchange Administration Center and then select Edit to view properties of the certificate. The thumbprint value is shown in the Exchange Certificate window.
Run the Get-ExchangeCertificate cmdlet to return a list of all certificates installed on the server with their thumbprint values.
Parameters
The BinaryEncoded switch specifies whether to encode the new certificate request by using Distinguished Encoding Rules (DER). You don't need to specify a value with this switch.
If you don't use this switch, the request is Base64 encoded.
This switch is available only when you use the GenerateRequest switch.
For Base64 encoded requests, you send the contents of the file to the certificate authority. For requests that are encoded by DER, you send the certificate file itself.
The Confirm switch specifies whether to show or hide the confirmation prompt. How this switch affects the cmdlet depends on if the cmdlet requires confirmation before proceeding.
The DomainController parameter specifies the domain controller that's used by this cmdlet to read data from or write data to Active Directory. You identify the domain controller by its fully qualified domain name (FQDN). For example, dc01.contoso.com.
The DomainController parameter isn't supported on Edge Transport servers. An Edge Transport server uses the local instance of Active Directory Lightweight Directory Services (AD LDS) to read and write data.
The DomainName parameter specifies one or more FQDNs or server names for theSubject Alternative Namefield (also known as the Subject Alt Name or SAN field) of the certificate request or self-signed certificate.
If the value in the certificate's Subject field doesn't match the destination server name or FQDN, the requestor looks for a match in the Subject Alternative Name field.
Typically, values include server names (for example, Mailbox01) and FQDNs (for example, mail.contoso.com). You can specify multiple values separated by commas. Valuescan contain the characters a through z, 0 through 9, and the hyphen (-). The length of the domain name can't exceed 255 characters.
You must complete research projects that will overcome it, otherwise your diplomatic actions will be paralyze for a long time. You should also note that the low political power growth of France is slowed even more. Hearts of iron free. France has very interesting defensive properties that allow you plan your military operations quite well in the short term. You should increase it with the help of national focuses directed at the said index. If you don't do that your country will quickly surrender after the global conflict starts.
The default value includes the name and FQDN of the Exchange server when both of the following conditions are true:
New Exchangecertificate Generaterequ…
The Force switch specifies whether to suppress warning or confirmation messages. You can use this switch to run tasks programmatically where prompting for administrative input is inappropriate. You don't need to specify a value with this switch.
By default, when you create a self-signed certificate that's enabled for SMTP (no Services parameter, or the Services parameter contains the value SMTP), you're prompted to replace the existing default SMTP certificate with the new one that you're creating. If you use the Force switch, the new SMTP certificate automatically replaces the existing SMTP certificate without asking.
The FriendlyName parameter specifies a friendly name for the certificate request or self-signed certificate. The value must be less than 64 characters.
The default value is Microsoft Exchange. The friendly name value is descriptive text, and doesn't affect the functionality of the certificate.
The GenerateRequest switch specifies that you're creating a certificate request for a certification authority (CA). You don't need to specify a value with this switch.
This switch, together with the RequestFile parameter, generates a PKCS #10 certificate request that you send to the CA. How you send the information depends on the CA, but typically, for Base64 encoded requests, you paste the contents in an email message or in the request form on the CA's web site.
After you install the certificate from the certification authority by using the Import-ExchangeCertificate cmdlet, you use the Enable-ExchangeCertficate cmdlet to enable the certificate for Exchange services.
If you don't use this switch,thecommand creates a new self-signed certificate on the Exchange server.
The IncludeAcceptedDomains switch specifies that all accepted domains in the Exchange organization are included in the Subject Alternative Name field of the certificate request or self-signed certificate. You don't need to specify a value with this switch.
When you use this switch:
The IncludeAutoDiscover switch specifies whether to add a Subject Alternative Namevalue with the prefix autodiscover for each accepted domain in the Exchange organization. You don't need to specify a value with this switch.
For example, if the organization has the accepted domains woodgrovebank.com and woodgrovebank.co.uk, using this switch results in the addition of the following values in the Subject Alternative Name field:
Root Canal
When you use this switch:
The IncludeServerFQDN switch specifies that the FQDN of the Exchange server is included in the Subject Alternative Name field of the new certificate request or self-signed certificate. You don't need to specify a value with this switch.
When you use this switch, and you've already included the server's FQDN in the DomainName parameter, the value isn't duplicated in the Subject Alternative Name field.
The IncludeServerNetBIOSName switch specifies that the NetBIOS name of the Exchange server is included in the Subject Alternative Name field of the new certificate request or self-signed certificate. You don't need to specify a value with this switch
When you use this switch, and you've already included the server's NetBIOS name in the DomainName parameter, the value isn't duplicated in the Subject Alternative Name field.
This parameter has been deprecated and is no longer used.
The KeySize parameter specifies the size (in bits) of the RSA public key that's associated with the new certificate request or self-signed certificate. Valid values are:
The PrivateKeyExportable parameter specifies whether the new self-signed certificate has an exportable private key, and controls whether you can export the certificate from the server (and import the certificate on other servers). Valid values are:
This parameter is only meaningful for new self-signed certificates.
The RequestFile parameter specifies the name and path of the certificate request file. The file contains the same information that's displayed on-screen when you generate a Base64 encoded certificate request (you don't use the BinaryEncoded switch).
You can use a local path if the certificate or certificate request is located on the same Exchange server where you're running the command. Otherwise, use a UNC path (<Server><Share>). If the value contains spaces, enclose the value in quotation marks (').
You can use this parameter only when you use the GenerateRequest switch.
The Server parameter specifies the Exchange server where you want to run this command. You can use any value that uniquely identifies the server. For example:
If you don't use this parameter, the command is run on the local server.
The Services parameter specifies the Exchange services that the new self-signed certificate is enabled for. Valid values are:
You can specify multiple values separated by commas. The default values are IMAP,POP, and SMTP.
You can't use this parameter with the GenerateRequest switch.
Once you enable a certificate for a service, you can't remove the service from the certificate.
The SubjectKeyIdentifier parameter specifies the unique subject key identifier for a newself-signed certificate. For example, run the command: $ski = [System.Guid]::NewGuid().ToString('N'), and use the value $ski for this parameter.
The SubjectName parameter specifies the Subject field of the certificate request or self-signed certificate.
Every certificate requires a value for the Subject field, and only one value is allowed. The requestor attempts to match the destination server name or FQDN with the common name (CN) value of subject.
This parameter uses the syntax: [C=<CountryOrRegion>,S=<StateOrProvince>,L=LocalityOrCity,O=<Organization>,OU=<Department>],CN=<HostNameOrFQDN>. Although the only required value is CN=<HostNameOrFQDN>, you should always include C=<CountryOrRegion> for certificate requests, but other values might also be required by the certification authority.
For example, if you want the certificate's subject to be mail.contoso.com in the United States, you can use any of the following values:
If you don't use this parameter, the default value is the name of the Exchange server where you run the command (for example, CN=Mailbox01).
For a subject alternative name (SAN) certificate, you should choose one of the values from the DomainName parameter to use in the SubjectName value. In fact, the CN value that you specify for SubjectName is automatically included in the DomainName values.
For a wildcard certificate, use a SubjectName value that contains the wildcard character (*). For example, C=US,CN=*.contoso.com.
The WhatIf switch simulates the actions of the command. You can use this switch to view the changes that would occur without actually applying those changes. You don't need to specify a value with this switch.
Inputs
To see the input types that this cmdlet accepts, see Cmdlet Input and Output Types (https://go.microsoft.com/fwlink/p/?LinkId=616387). If the Input Type field for a cmdlet is blank, the cmdlet doesn't accept input data.
Outputs
To see the return types, which are also known as output types, that this cmdlet accepts, see Cmdlet Input and Output Types (https://go.microsoft.com/fwlink/p/?LinkId=616387). If the Output Type field is blank, the cmdlet doesn't return data.
Related LinksComments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |