Do you have anonymous access turned on for the zone?
Anonymous is set to "All Zones" None - no policy
I also verified that the root certificate was installed. Still unable to send the emails.
ccoulson wrote:
Do you have anonymous access turned on for the zone?
Anonymous is enabled.
It's been resolved. It turn out DNS issue. Public URL is not resolved properly from inside. That's why I got Socket connection issue.
Thanks for your help on this!
Trixie: I'm not sure. If you'd like you can purchase a support plan at http://www.visigo.com/purchase.html and i'll do a screen sharing session with you and work at solving the problem in your environment.
Thanks but after many test membership request and looking through thousands of lines logs and I found the Trust info. It appears that the certificate was installed as "Personal Certificates" instead of Root CA. Just trying to get the person who installed it to correct their mistake.
Question in regard to the emails that are sent out - Will modifying the emails cause a problem??
You mean modifying the xslt templates for the emails? No, that shouldn't cause a problem at all.
Great!! Thank you so much for all your help
Hi Chris,
Just to give you an update and see your thoughts on this issue. The certificate needed to be repaired, once repaired I added to it to SharePoint. There are two certificates listed under Mange Trust - one is the SharePoint Certificate and the other root CA needed. I then try to register an individual and receive the Unknown Error again. Logs show:
Critical An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=SharePoint Services, OU=SharePoint, O=Microsoft, C=US\nIssuer Name: CN=SharePoint Root Authority, OU=SharePoint, O=Microsoft, C=US\nThumbprint: C36240461511D6FB3BFE479C04AADC9E1B6DB90E\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority.. af099337-f2b1-4b34-9876-0ddf58440ea6
Note - if I remove the local certificate (list above from the log) the webpart works fine.
I've opened an incident with Microsoft. As usual, MS says it's a problem with the Web Part - the web part must be having an issue determining which certificate to use. Have you seen this before?
Thank you once again
Actually you should only need the root certificate to be trusted, and then by default all certificates generated by that root authority are trusted. That's how I have it in all of my configurations.
Of course I wouldn't think that adding the actual certificate should cause problems. From the error my guess is that the problem is that the certificate is a self generated certificate. All of my testing has been with certificates from real certificate authorities. I expect you can probably get rid of this error by setting up windows to recognize the authority that generated this certificate as a trusted authority. I'd try following a guide like this one:
I'm back - still having issues. After 3 days on te phone with Microsoft I am no longer receiving:
Critical An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=SharePoint Services, OU=SharePoint, O=Microsoft, C=US\nIssuer Name: CN=SharePoint Root Authority, OU=SharePoint, O=Microsoft, C=US\nThumbprint: C36240461511D6FB3BFE479C04AADC9E1B6DB90E\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority.. af099337-f2b1-4b34-9876-0ddf58440ea6
I am now receiving:
An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=client.king-worldwide.com, O="D.F. King & Co., Inc.", L=New York, S=New York, C=US, SERIALNUMBER=2283065, OID.1.3.6.1.4.1.311.60.2.1.2=Delaware, OID.1.3.6.1.4.1.311.60.2.1.3=US, OID.2.5.4.15=Private Organization\nIssuer Name: CN=DigiCert High Assurance EV CA-1, OU=www.digicert.com, O=DigiCert Inc, C=US\nThumbprint: 7DE9ED8A075CD3E7933BD1CDFE7AB943D3C9BCD9\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority.
I followed all of the directions in the blogs (in your reply above) and still no luck. I even undeployed and deployed again. I'm at a loss
Since you're now receiving ' The root of the certificate chain is not a trusted root authority' - all you should have to do it export the root of the certificate and add it to the trusted certificates in SharePoint. To get the root certificate:
-> Certificate Information -> Certification Path -> View Certificate on top certificate in the path -> Details tab -> Copy to File...
An update for others who may be having the same issue. This problem was finally resolved. Microsoft support was useless - inexperienced support person who would not escalated the issue even after emailing their team leader and their manager. Luckily the certificate company support person made some suggestions that helped. Namely, add the Entrust certificate and it worked.
Hello, I am experiencing a similar issue. The Membership Request webpart returns 'unknown error' on submit. My logs says "...The root of the certificate chain is not a trusted root authority..." I have a wildcard certificate installed under Personal and have exported it and added it to my trust relationships in SharePoint. The Password Reset sends email fine, so I'm confused why one webpart works and the other doesn't. Do I need to move the cert from Personal to Trusted Root? What would be the optimal settings to have all the webparts functioning? Thanks!
If the password reset works fine - maybe you have <mailSettings> in the web.config - so the password recovery web part is actually sending the default email instead of the templated email. If it's working and using the templated email, the first line of the email will be:
You have requested this mail because you have forgotten your password to ...
As for the "root of the certificate chain" error - the issue is that you've probably just added the certificate to your trust relationships. It's not the actual certificate you add, but the root certificate. To do that, open up the certificate properties, click the 'Certification Path' tab, select the topmost certificate, click 'View Certificate', click 'Details', click 'Copy to File'. Finally, add that exported certificate to your trust relationships.
Now for some good news. I'm just testing the next version of the FBA Pack. It fixes both these errors:
Having <mailSettings> in the web.config still allows the password recovery web part to function properly.
The email templates are no longer stored in files, so they no longer have any SSL/trust issues.
If testing goes well, i'll hopefully have a new release out this weekend.
Woo Hoo - guess I had the wrong cert referenced. Membership email is working! I look forward to the new rev - keep up the stellar work!
I had a similar issue as above and after weeks of troubleshooting finally found my issue. I had the FBA pack working 100% in dev but no matter what i tried couldn’t get it to work in Prod. Was getting an exception
"System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond "when it tried to load the XSLT.
The solution for me included the certificate issue above but also was related to the DNS IP address. Our site is NAT'ed behind a firewall and the IP of the server is not the same as the public IP. The IP that the code had gotten was the External IP. Then it clicked, on Dev i had added local host entry’s to test access to the site (hence local DNS IP to 127.0.0.1). After a quick change on production to test, registration and other email related controls worked first time.
With a temporary fix in place, I now need to find something a bit more unwavering.
Hopefully this helps someone else.
Just an FYI, as of version 1.3, the xslt/ssl loading errors should no longer be happening due to a change in the way the xslt is loaded.
I am having a related problem. I had installed and configured fba. When using the register web part, I am getting an unknown error but there is no detail being logged in any of the log files (Sharepoint, IIS, Events).
Please help.
Please help.
Usually an unknown error in the register web parts is due to an inability to send the email. There always should be an error message in the SharePoint log file (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS) for an unknown
error.