noooodlez
asked on
Exchange 2007 SSL certificate problem
Hi
I am having an issue with my SSL config following renewal of my ssl certificate
I followed the method detailed here .....http://support.godaddy.com /help/arti cle/4877/i nstalling- an-ssl-cer tificate-i n-microsof t-exchange -server-20 07
This is the same method I followed 3 years ago when I originally imported the signed cert. The only difference being I had to drop my internal uris (eg domaincontroller.attwaters .local).
Imported through Exch Management Console and enabled for IIS, IMAP and SMTP.
get-exchangecertificate shows.....
Thumbprint Services Subject
7E182A1AFB72AF7D43105C957E 8CE1 IP.WS CN=mail.domain.com, O...
C0F43600D7E7B56B511647436E 3B10 ..... CN=domains-DCSERVER-CA
599AEFEBF09B3821E94A6A592A 8AF1 ..... CN=DCSERVER.domain.local
A718B39B69B7AD03D2B5E00FAE F51A ..... CN=domains-DCSERVER-CA
71396D438AB2719652253C8E4E 18C1 ..... CN=WMSvc-WIN-DD4E4LZ288I
My godaddy certificate
CN = mail.domain.com
OU = Domain Control Validated
DNS Name=mail.domain.com
DNS Name=www.mail.domain.com
DNS Name=autodiscover.domain.c om
DNS Name=remote.domain.com
Since updating the cert, OWA, OAB, web services and RPC over HTTP FAIL.
OWA (Internal) gives a generic "Internet connectivity has been lost." message.
Using MS Remote Connectivity Analyser, I get.....
Wasn't able to obtain the remote SSL certificate.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
Other tools suggest that no certificate is offered on 443.
I have revoked, generated new csrs and repeated multiple times. iisresets, reboot etc and no joy.
Has anyone got any ideas where I need to look next?
Of, for info, SBS2008!
Many thanks.
I am having an issue with my SSL config following renewal of my ssl certificate
I followed the method detailed here .....http://support.godaddy.com
This is the same method I followed 3 years ago when I originally imported the signed cert. The only difference being I had to drop my internal uris (eg domaincontroller.attwaters
Imported through Exch Management Console and enabled for IIS, IMAP and SMTP.
get-exchangecertificate shows.....
Thumbprint Services Subject
7E182A1AFB72AF7D43105C957E
C0F43600D7E7B56B511647436E
599AEFEBF09B3821E94A6A592A
A718B39B69B7AD03D2B5E00FAE
71396D438AB2719652253C8E4E
My godaddy certificate
CN = mail.domain.com
OU = Domain Control Validated
DNS Name=mail.domain.com
DNS Name=www.mail.domain.com
DNS Name=autodiscover.domain.c
DNS Name=remote.domain.com
Since updating the cert, OWA, OAB, web services and RPC over HTTP FAIL.
OWA (Internal) gives a generic "Internet connectivity has been lost." message.
Using MS Remote Connectivity Analyser, I get.....
Wasn't able to obtain the remote SSL certificate.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
Other tools suggest that no certificate is offered on 443.
I have revoked, generated new csrs and repeated multiple times. iisresets, reboot etc and no joy.
Has anyone got any ideas where I need to look next?
Of, for info, SBS2008!
Many thanks.
They are two unrelated problems.
The second issue you have posted is easy to resolve. Just go in to EMS and run
new-exchangecertificate
No switches or other options. An internal self signed certificate will be created that will stop the SMTP error message.
As for the first one - have you removed the old certificate?
If you run get-exchangecertificate do you see the new certificate and it is bound to the IIS service? (W).
Did you enable the certificate using the SBS wizard, or through Exchange?
Simon.
The second issue you have posted is easy to resolve. Just go in to EMS and run
new-exchangecertificate
No switches or other options. An internal self signed certificate will be created that will stop the SMTP error message.
As for the first one - have you removed the old certificate?
If you run get-exchangecertificate do you see the new certificate and it is bound to the IIS service? (W).
Did you enable the certificate using the SBS wizard, or through Exchange?
Simon.
ASKER
Hi
I enabled the certificate through Exchange. The SBS wizard is broken (I inherited the network with a 192.0.0.x subnet which is technically a public subnet), The SBS wizard will not let me go beyond "connect to internet".
I ran the new-exchangecertificate command which worked with this message.
WARNING: This certificate will not be used for external TLS connections with an FQDN of 'DC.domain.local' because the CA-signed certificate with thumbprint '7BD905068E999AEFEBF09B982 1E94A6A592 A8AF0' takes precedence. The following connectors match that FQDN: Default Connector.
The 7bd9..... certificate is one that I was messing with, enabling services, and now cannot disable the SMTP service on it.
Do I need to do something with the connector to tell it to use the new certificate. I cannot see any options here, other than to use TLS.
Port redirection (443) on my router is unchanged. The request must get to my exchange box via the connector, so why is no certificate being offered?
I have also noticed that
Get-OABVirtualDirectory | fl InternalUrl, ExternalUrl
Get-WebServicesVirtualDire ctory | fl InternalUrl, ExternalUrl
only return internal addresses and not external
InternalUrl : https://server/ews/exchange.asmx
ExternalUrl :
InternalUrl : https://server/oab
ExternalUrl :
Does this look correct?
The old expired certificate is still in my personal store, but not imported in exchange.
I enabled the certificate through Exchange. The SBS wizard is broken (I inherited the network with a 192.0.0.x subnet which is technically a public subnet), The SBS wizard will not let me go beyond "connect to internet".
I ran the new-exchangecertificate command which worked with this message.
WARNING: This certificate will not be used for external TLS connections with an FQDN of 'DC.domain.local' because the CA-signed certificate with thumbprint '7BD905068E999AEFEBF09B982
The 7bd9..... certificate is one that I was messing with, enabling services, and now cannot disable the SMTP service on it.
Do I need to do something with the connector to tell it to use the new certificate. I cannot see any options here, other than to use TLS.
Port redirection (443) on my router is unchanged. The request must get to my exchange box via the connector, so why is no certificate being offered?
I have also noticed that
Get-OABVirtualDirectory | fl InternalUrl, ExternalUrl
Get-WebServicesVirtualDire
only return internal addresses and not external
InternalUrl : https://server/ews/exchange.asmx
ExternalUrl :
InternalUrl : https://server/oab
ExternalUrl :
Does this look correct?
The old expired certificate is still in my personal store, but not imported in exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Got that, but there's on way I can change the subnet range on this site! No, the connect to the internet wizard will not complete. It refuses to put the ip range in.
The fix my network wizard is a good starting point. I had forgotten about that. I will run it later and see what it flags up!
The fix my network wizard is a good starting point. I had forgotten about that. I will run it later and see what it flags up!
ASKER
I ran through the fix my network wizard last night and let it run a couple of fixes.
On the SBS Console 'Activity' tab I could still see the expired UCC cert. I managed to delete the cert and allow SBS to generate new certs (it created 2).
I cannot run many options on the connectivity tab as they a hinge on the "connect to the internet" function.
get exchangecertificate command now gives the output in the attached jpg file.
================== ==================
Disallowing internal domains on UCC certificates has complicated this somewhat. I need to work out how I now service my clients using 2 certificates.
What is my strategy for running on 2 certs??
What services should I see against the get-exchangecertificate output.
Currently state of play:
OWA (internal) is happy - https://sites/owa
Outlook client (internal) works - with a certificate error ('sites' certificate)
INCOMING SMTP IS BROKEN! I am POP3ing emails in! SMTP connects with 421 4.3.2 Service not available, closing transmission channel.
What next?
ucccert.jpg
On the SBS Console 'Activity' tab I could still see the expired UCC cert. I managed to delete the cert and allow SBS to generate new certs (it created 2).
I cannot run many options on the connectivity tab as they a hinge on the "connect to the internet" function.
get exchangecertificate command now gives the output in the attached jpg file.
================== ==================
Disallowing internal domains on UCC certificates has complicated this somewhat. I need to work out how I now service my clients using 2 certificates.
What is my strategy for running on 2 certs??
What services should I see against the get-exchangecertificate output.
Currently state of play:
OWA (internal) is happy - https://sites/owa
Outlook client (internal) works - with a certificate error ('sites' certificate)
INCOMING SMTP IS BROKEN! I am POP3ing emails in! SMTP connects with 421 4.3.2 Service not available, closing transmission channel.
What next?
ucccert.jpg
Sounds like the server is very broken.
When you try and run the Connect to the Internet wizard, what happens?
You cannot run two certificates - it is perfectly possible to run a single certificate. Outlook wouldn't normally use the Sites certificate, so there is something wrong there, probably again due to the wizards not being run (sorry to be boring and go on about the wizards).
Service not available usually means lack of disk space, or there is a problem with the Receive Connector configuration. Again using the wizards will resolve that in most cases.
Simon.
When you try and run the Connect to the Internet wizard, what happens?
You cannot run two certificates - it is perfectly possible to run a single certificate. Outlook wouldn't normally use the Sites certificate, so there is something wrong there, probably again due to the wizards not being run (sorry to be boring and go on about the wizards).
Service not available usually means lack of disk space, or there is a problem with the Receive Connector configuration. Again using the wizards will resolve that in most cases.
Simon.
ASKER
Hi
I set up a router on a private IP, changed the server IP and allowed SBS to run it's wizards.
I have taken a snapshot of the certs / services as they are (the services are all over the place, and using 'enable-exchangecertificat e -thumbprint xxx -services "None" doesn't seem to work.
I'm currently letting sbs create(csr) it's own certificate using the remote.domain.com address and trying to keep everything as 'out of the box' as possible. See if it comes back up.
I set up a router on a private IP, changed the server IP and allowed SBS to run it's wizards.
I have taken a snapshot of the certs / services as they are (the services are all over the place, and using 'enable-exchangecertificat
I'm currently letting sbs create(csr) it's own certificate using the remote.domain.com address and trying to keep everything as 'out of the box' as possible. See if it comes back up.
You cannot disable SSL certificates in that way. All you can do is enable other certificates for the services.
Running the wizards will generate the certificate that is required for internal use. If you have a trusted certificate on the server for remote.example.com then you can use the wizard to enable it. If it is for another name then you have two options.
1. Use the wizards to change to the name on the SSL certificate (you have to choose the Advanced option).
2. See if the SSL provider will allow you to rekey the certificate with the preferred remote.example.com host name.
Simon.
Running the wizards will generate the certificate that is required for internal use. If you have a trusted certificate on the server for remote.example.com then you can use the wizard to enable it. If it is for another name then you have two options.
1. Use the wizards to change to the name on the SSL certificate (you have to choose the Advanced option).
2. See if the SSL provider will allow you to rekey the certificate with the preferred remote.example.com host name.
Simon.
ASKER
Hi Simon.
Since temporarily changing subnet range, I have been able to run through the wizards, it was just the initial check on the "connect to the internet" wizard that blocked me!
HOWEVER, running through the "connect to internet" wizard on the wrong ip range broke some even more fundamental areas of the system, such as moving the DNS entries for the DC to the temporary subnet range!!!
My network really did not like this. Also, this caused the RODC on our remote network to lose it's link back to the PDC and fail!!
After a day of tweaking, and running the fix my network wizard over and over I am 90% back up and running.
Seems you were right to keep going on about the wizards!! My network is now only slightly broken!
Now I have one fundamental issue.
My UCC certificate used to service multiple domains. (i.e., mail.domain.com, remote.domain.com, DC.domaininternal.local etc).
http://support.godaddy.com /help/arti cle/6935/p hasing-out -intranet- names-and- reserved-i p-addresse s-in-ssls
Now I cannot have my internal DC as an alt name on my UCC certificate, all of my internal outlook clients are complaining of certificate errors!!! - As you have stated above, we can run with one certifricate, and this is the wrong one for internal Outlook.
I have tried routing 'mail.domain.com' direct to our DC through our internal DNS, however, when I create an exchange account in outlook it just resolves it straight to our SBS box (and ignored the dns entry which would serve the correct certificate)!
Is it possible to get everything happy? How do I set up my certificates to handle internal and external requests properly?
For info, OWA is happily using the remote.domain.com certificate and getting serviced properly!.
Nearly there. The vultures are off my back!
Since temporarily changing subnet range, I have been able to run through the wizards, it was just the initial check on the "connect to the internet" wizard that blocked me!
HOWEVER, running through the "connect to internet" wizard on the wrong ip range broke some even more fundamental areas of the system, such as moving the DNS entries for the DC to the temporary subnet range!!!
My network really did not like this. Also, this caused the RODC on our remote network to lose it's link back to the PDC and fail!!
After a day of tweaking, and running the fix my network wizard over and over I am 90% back up and running.
Seems you were right to keep going on about the wizards!! My network is now only slightly broken!
Now I have one fundamental issue.
My UCC certificate used to service multiple domains. (i.e., mail.domain.com, remote.domain.com, DC.domaininternal.local etc).
http://support.godaddy.com
Now I cannot have my internal DC as an alt name on my UCC certificate, all of my internal outlook clients are complaining of certificate errors!!! - As you have stated above, we can run with one certifricate, and this is the wrong one for internal Outlook.
I have tried routing 'mail.domain.com' direct to our DC through our internal DNS, however, when I create an exchange account in outlook it just resolves it straight to our SBS box (and ignored the dns entry which would serve the correct certificate)!
Is it possible to get everything happy? How do I set up my certificates to handle internal and external requests properly?
For info, OWA is happily using the remote.domain.com certificate and getting serviced properly!.
Nearly there. The vultures are off my back!
ASKER
Oh, and for info, when I tried to move the exchange services between the certificates, the SMTP service 'stuck'. I ended up with SMTP on 4 certificates and no real way of working out the precedence.
Clearing out the dead wood from the exchange certificates simplified the job somewhat.
Clearing out the dead wood from the exchange certificates simplified the job somewhat.
On the certificates for SMTP only, that is really easy to deal with.
Delete them all using remove-exchangecertificate .
One of them it will throw an error about. For that one, leave it alone, as that is the one being used by the system. That should leave you with two certificates - a self signed one and the trusted one.
As long as you have gone through the wizards, Exchange should start using the external host name internally. It will create the DNS records.
Crucial point here - the server must be the ONLY DNS server going to the clients, and in the network configuration and it must also be the DHCP server - not your router or anything else.
Simon.
Delete them all using remove-exchangecertificate
One of them it will throw an error about. For that one, leave it alone, as that is the one being used by the system. That should leave you with two certificates - a self signed one and the trusted one.
As long as you have gone through the wizards, Exchange should start using the external host name internally. It will create the DNS records.
Crucial point here - the server must be the ONLY DNS server going to the clients, and in the network configuration and it must also be the DHCP server - not your router or anything else.
Simon.
ASKER
Hi.
I haven't deleted the remainder of the certificates yet, but EXCHANGE is being serviced by my external certificate.
This includes, mail.domain.com, remote.domain.com, autodiscover.domain.com etc.
DNS to remote.domain.com does resolve internally! I have DNS on my RODC replicating, so isn't causing an issue.
Ideally my outlook clients should look to remote.domain.com to resolve the correct certificate (or mail.domain.com if I wish).
Thanks for your help on this Simon!
If I delete the Outlook profile, and set a new profile / exchange account, manually point it to remote.domain.com it automatically resolves the dns and configures on server.domain.local and serves the signed cert.
Same goes if I let it configure it's self. The only reference to
The problem to me is now on the client side. Not the end of the world, but all my users are asking what the cert error is all about!!!!
I haven't deleted the remainder of the certificates yet, but EXCHANGE is being serviced by my external certificate.
This includes, mail.domain.com, remote.domain.com, autodiscover.domain.com etc.
DNS to remote.domain.com does resolve internally! I have DNS on my RODC replicating, so isn't causing an issue.
Ideally my outlook clients should look to remote.domain.com to resolve the correct certificate (or mail.domain.com if I wish).
Thanks for your help on this Simon!
If I delete the Outlook profile, and set a new profile / exchange account, manually point it to remote.domain.com it automatically resolves the dns and configures on server.domain.local and serves the signed cert.
Same goes if I let it configure it's self. The only reference to
The problem to me is now on the client side. Not the end of the world, but all my users are asking what the cert error is all about!!!!
You shouldn't get an SSL error at all.
The first thing I would do is when you get the error, open the certificate message and see what URL it is referring to.
Then do an Autodiscover test http://semb.ee/adt and see whether one of the URLs is wrong.
Simon.
The first thing I would do is when you get the error, open the certificate message and see what URL it is referring to.
Then do an Autodiscover test http://semb.ee/adt and see whether one of the URLs is wrong.
Simon.
ASKER
Event Type: Error
Event Source: MSExchangeTransport
Event Category: TransportService
Event ID: 12014
Date: 31/10/2013
Time: 07:49:38
User: N/A
Computer: DC.DOMAINs.local
Description:
Microsoft Exchange could not find a certificate that contains the domain name DC.DOMAINs.local in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default DC with a FQDN parameter of DC.DOMAINs.local. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate
Seems to be suggesting that I need to use the smtp service on a certificate created by our internal CA!?