ecco alcuni link che guidano passo passo in questa procedura.
Guida PassoPasso
Generazione script cert req
Comando Powershell per generare la richiesta del certificato (cert req) che andrà poi passata alla CA
(il comando va lanciato sulla PS del server in oggetto)
New-ExchangeCertificate -GenerateRequest -Path c:\SrvMail_studio_re.csr -KeySize 2048 -SubjectName "c=IT, s=Italy, l=Correggio, o=StudioAvvocato, ou=IT, cn=SrvMail.studio.re" -DomainName srvmail, srvmail.studio.re, autodiscover.studioavvocato.it, webmail.studioavvocato.it, ippubblico.xxx.xxx.xxx -PrivateKeyExportable $True
(il comando sopra funziona per le versioni 2007 e 2010. in Exchange 2013 la sintassi è leggermente cambiata)
New-ExchangeCertificate -FriendlyName 'Contoso Exchange 15 Certificate' -GenerateRequest -requestfile c:\cert\req02.csr -KeySize 2048 -SubjectName "c=IT, s=Italy, l=Reggio, o=MioDomino, ou=IT, cn=mail.MioDomino.it" -DomainName srvmail, mail.MioDomino.local, srv-exc2013, srv-exc2013.MioDomino.local, autodiscover.MioDomino.local, autodiscover.MioDomino.it, webmail.MioDomino.it, AutoDiscover.MioDomino1.it, AutoDiscover.MioDomino2.it -PrivateKeyExportable $True
cercando di firmare la CRL appena creato sulla propria CA si otterrà molto probabilmente un errore relativo al template simile a questo: 0x80094801
La prima soluzione da provare è lanciare questo comando da prompt (con privilegi elevati) sul server CA
certreq -submit -attrib “CertificateTemplate:WebServer” c:\SrvMail_studio_re.csr
la seconda strada da percorrere è tentare il rilascio del certificato via web:
sul server CA disabilitare la protezione di internet explorer se attiva e andare sul sito http://localhost/certsrv
seguire le istruzioni per il rilascio del cerrtificato > Inviare una richiesta di certificato utilizzando un file CMC o PKCS #10 codificato in base 64 o una richiesta di rinnovo utilizzando un file PKCS #7 codificato in base 64 . > accertarsi di selezionare dal menu a tendina la voce "web server"
Se anche questa non funziona si rimanda qualche ricerca con google.
Ricerca 1
Ricerca 2
Una volta ottenuto il nostro certificato dovremo importarlo sul server Exchange:
Import-ExchangeCertificate -Path c:\certexchange.cer
ora il certificato è da abilitare:
get-exchangecertificate | fl
segnarsi il thumbprint
Enable-exchangecertificate -thumbprint EB00B20460A8A217426ECA38A63DA12E90E17784 -services SMTP,IIS,POP,IMAP
opzionale rimuovere il vecchio certificato per pulizia.
Remove-ExchangeCertificate -Thumbprint 5253AEB2C4D71B82828EC0FA03D8E346FE0F8220 -WhatIf
Exchange 2007 - Multiple Name SSL Certificate Request and Installation
Exchange 2007 is designed to be used with Unified Communications (also referred to as SAN (subject alternative name) or multiple domain certificate). This is different to a wild card certificate as it allows different domains to be used in the same certificate, such as example.com, example.co.uk and example.local.
A version of this article originally appeared on our director's blog.
However because of the way that SSL certificates are managed, this has caused some confusion for Exchange administrators, particularly those that have come from Exchange 2003, where it is simply done through IIS. In Exchange 2007, SSL is integrated in to the product.
When Exchange 2007 is installed, it will install a self signed certificate. This should be considered a place holder for a commercial trusted certificate. The self signed certificate that is installed is not supported for use with either Outlook Anywhere or Exchange ActiveSync.
Throughout this article the following domains are used as examples:
example.com
This is a public facing registered domain name
example.local
This is a private domain, or your internal domain name.
However if your public and internal domain name are one and the same, then this isn't a problem, it just means one less name on the certificate.
IMPORTANT
Read through this entire article before starting the process. It covers the steps required in some depth, along with a complete list of what to do in which order.
The URLs to use.
The first thing to consider is what URLs to use. This has caused some confusion for Exchange administrators in the past.
The most straight forward scheme is to use the same names for as many services as possible. This reduces the confusion for the end users and limits the number of names you have to put in to the certificate.
Therefore you have four names:
mail.example.com
This is the common name and appears in the SSL certificate. If it is used for the MX records then it will allow your server to accept TLS (aka SSL over SMTP) traffic inbound. Also use it for the address for OWA, IMAP, POP3, Exchange ActiveSync (EAS) and Outlook Anywhere. Set this name as your PTR (aka reverse DNS) on your external public IP address.
By having this name as the public face of your Exchange server, it will ensure that anything that doesn't support the additional names of the certificate can continue to work. A good example is RPC over HTTPS for Outlook 2003.
autodiscover.example.com
If the server is going to support more than one domain, where users have the domain as their primary email address, then that needs to be included as well. The autodiscover process simply tries to use autodiscover.example.com - where example.com is the domain after the @ sign in the email address.
server.example.local
This is the Exchange server's real internal name
server
This is the Exchange server's NETBIOS name
The server name is used internally. If you have UM installed then UM will not use the certificate unless it has the server's real name in its SAN list.
SBS 2008
If you are installing the certificate on an SBS 2008 system, then you should also include the host name "sites". Full instructions on setting up a commercial SSL certificate are here.
Names You do NOT have to include
example.com
You may also see recommendations that "example.com" (ie nothing in front of the domain) is also included in the list. This doesn't really achieve a great deal, as for most sites the root of the domain (example.com) should point to the public web site, not a private resource like OWA. Many people have stopped entering www in front of the domain - this is clearly shown by the number of adverts in media that do not feature the "www".
autodiscover.example.local
This isn't required as internal users will get their autodiscover information from the domain.
DNS Setup
Once you have decided on the URLs to use, you need to configure DNS.
Ideally, all of the external URLs (anything ending in example.com) should resolve internally as well. This allows you to test things on your network and mobile devices that connect to an internal wireless network can work without changing the settings.
If you are going to have Outlook 2007 or higher clients on your internal network, where the host machine is NOT going to be a member of the domain, then the autodiscover URL must resolve internally so that Outlook works correctly.
The usual way to ensure the URLs resolve correctly is to configure a split DNS system.
The Certificate Request.
The certificate request is an Exchange Management Shell (EMS) command and can therefore be very complex to configure and get correct. However Digicert have created a web page that will create the command for you, which can be found here. Create the command and then copy and paste it in to a EMS window.
You do not have to use them for the SSL certificate itself.
Once the command has been run, it will generate a certificate request. You need to open that in notepad and copy and paste the complete request in to the window as per the instructions from the SSL certificate supplier. You will then get a response back to import.
The Certificate Import
Again another nice Microsoft article that can be shortened to something quite simple.
http://technet.microsoft.com/en-us/library/bb124424.aspx
This is the command that you need to use to import the certificate response that you have received from your supplier:
You may have additional instructions from the supplier, such as root and intermediate certificate installation which should be completed before importing the certificate response.
URL Changes within Exchange
The last area that can cause a problem is getting the URLs correct.
Unlike Exchange 2003, where you could address the server by any name that you liked as long as it resolved, Exchange 2007 requires things to match. Therefore you have to ensure that the URLs are set correctly in the application for the virtual directories, connectors etc.
The Full To Do List for Certificates on Exchange 2007
After the explanations of what needs to be done, what is the full list?
Setup the DNS names that you need to use, both internally and externally.
Generate the request here: https://www.digicert.com/easy-csr/exchange2007.htm
Post the resulting script in to an Exchange Management Shell command.
Use the Certificate Request file with your preferred SSL certificate supplier such as http://certificatesforexchange.com/ (use coupon code 50CN10 for 10% off the price of the multiple name certificate).
When you get the response back, save the file to the server. If you have used the above site to get the certificate, install the root and intermediate certificate as per the instructions that you have been supplied with.
Use the EMS command to import the Certificate Result file:
(where the certificate result is in C:\SSL and is called result.pfx)
Run get-exchangecertificate from the shell and you should see your new certificate listed. However you will notice that under "Services" it will be "....." . That is because the certificate is not enabled for any services.
Restart the Microsoft Exchange Transport Service if the server holds the Hub Transport role and run IISRESET if the server holds the Client Access Role. This will mean the certificate can be enabled immediately. If you cannot do either you will need to wait for Exchange to internally update before you can enable certificate. This can take 20 minutes or so.
If you are installing the certificate on SBS 2008, do NOT proceed any further, but refer to the dedicated SBS 2008 instructions here.
To enable the certificate, run the following command:
To get the thumb print, run get-exchangecertificate. It looks like a long series of random characters. Highlight the thumb print and then press enter to copy it.
Run get-exchangecertificate again to confirm the certificate is enabled for the four services.
If you are using the UM role, then you should also add UM to the above list.
As an alternative, you can run the command for each service as a separate item
Adjust the External URLs in Exchange to match the name of the certificate that you have purchased.
In EMC, change: OWA virtual directory, EAS virtual Directory, Outlook Anywhere, OAB virtual directory
In EMS (where EXCH is the server's real name)
Web Services
Unified Messaging (if installed)
Receive Connectors
These usually do not have to be changed because the FQDN value will match the server's real name and therefore that is included in the additional names of the certificate.
Send Connectors
Again, no change required because any SSL certificate used for sending email comes from the remote server.
Restart the Exchange services on all servers to allow the change to take effect. Outlook users, particularly those on Outlook Anywhere in Outlook 2007 should be asked to restart their session.
Outlook 2003 RPC over HTTPS
If you have changed the external name being used by RPC over HTTPS users on Outlook 2003 then they will have to change the configuration manually.
Testing
Once complete, test it using Outlook 2007. Hold down CTRL and right click on the Outlook icon in the system tray. Choose Test Autodiscover and run the tests to see what URLs are being issued.
For external testing, use the Test Exchange Connectivity Site web site from Microsoft.
Nessun commento:
Posta un commento
Lascia qui il tuo commento.