IK (besta niet zonder privacy)
HEB (fouten gemaakt die anderen niet mogen weten)
NIKS (is veilig in handen van de overheid)
TE (vaak worden data voor andere doeleinden gebruikt)
VERBERGEN (is de enige manier om daaraan te ontkomen)
Ook van een collega uit een artikel wat hij zat te lezen met betrekking tot de mogelijkheden die moderne technologie en specifiek het internet biedt en het gebruik of misbruik ervan.
http://www.microsoft.com/en-us/download/details.aspx?id=41701
On the above link you can download the “Configuring Claims-based Authentication for Microsoft Dynamics CRM Server” manual from Microsoft’s Download Center. I’ve only ran through the process of configuring claims-based authentication internally but still came across a few things in that I had to adjust compared to the document that was downloaded. Unfortunately Microsoft doesn’t allow you to make comments in the Download Center as they do on other websites they host.
1) In the chapter “Configure the AD FS server for claims” on page 29, you need to enter userPrincipalName or User-Principal-Name, not User Principal Name as stated in the document. If you type the first it will change into the second option, but taking over what was mentioned in the document will lead to the an “Invalid Argument” error and within the URL you will find ErrorCode=0x80040203.
2) With the above you have AD FS Management already open so go to AD FS -> Service -> Certificates and make sure there are no self-signed certificates there, I had to change the token-decrypting and token-signing certificates for which I used the ADFS Website certificate and this certificate is also used in the Claims-Based authentication wizard as they have to match (or other wise your encryption/decryption will fail), which was what led me looking for these settings in the first place. Errors that are found in the URL included : “The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.” or “An encrypted security token was received at the relying party which could not be decrypted. Configure the relying party with a suitable decryption certificate.” with the thumbprint of the certificate in there.
For the rest the document is good, however you need to read it very carefully as it is easy to overlook something. And with everything IT it is either 1 or 0. It works or it doesn’t.
As stated in the previous post, there where some issues with the Comodo Positive SSL implementation. Those where caused by the webserver supplying an incorrect certificate chain so verification failed on certain platforms, among those anything using Android as well as Firefox certificate stores.
A correct certificate chain shows the following certificates:
However when looking at the Windows certificate store it showed the following on the two servers I tested with:
And as this is published by any service using certificates any products actually verifying the whole chain will end up with a certificate failure. What essentially needs to be done is to fix the Windows certificate store to show you the first chain and not the second, as that resolves all the issues with Android, Firefox and maybe some others as well.
Comodo supplies the right certificates on their website, but I didn’t use that approach. When looking at the chain through Firefox (running on Ubuntu 14.04) it shows the chain as it should be, it also allows you to export the certificates in the chain. Those certificates I’ve imported into the Windows certificate store. The upper one has to go into the Trusted Root Certification Authorities container, the two others have to go into the Intermediate Certification Authorities container. I then noticed that it still didn’t show properly and searching by serial number I found a certificate in the Trusted Root Certification Authorities container that I exported and then removed. Once this was done it showed up correctly and errors on both Firefox and Android are gone.
Got it from a colleague of mine, he must have been wondering about my inlaws.
A young man was wandering, lost, in a forest when he came upon a small house. Knocking on the door he was greeted by an ancient Chinese man with a long, gray beard. “I’m lost,” said the man. “Can you put me up for the night?”
“Certainly,” the Chinese man said, “but on one condition. If you so much as lay a finger on my daughter I will inflict upon you the three worst Chinese tortures known to man.”
“OK,” said the man, thinking that the daughter must be pretty old as well, and entered the house. Before dinner the daughter came down the stairs. She was young, beautiful and had a fantastic figure. She was obviously attracted to the young man as she couldn’t keep her eyes off him during the meal. Remembering the old man’s warning he ignored her and went up to bed alone. But during the night he could bear it no longer and snuck into her room for a night of passion. He was careful to keep everything quiet so the old man wouldn’t hear and, near dawn, he crept back to his room, exhausted but happy.
He woke to feel a pressure on his chest. Opening his eyes he saw a large rock on his chest with a note on it that read, “Chinese Torture 1: Large rock on chest.” “Well, that’s pretty crappy,” he thought. “If that’s the best the old man can do then I don’t have much to worry about.” He picked the boulder up, walked over to the window and threw the boulder out. As he did so he noticed another note on it that read “Chinese Torture 2: Rock tied to left testicle.” In a panic he glanced down and saw the line that was already getting close to taut. Figuring that a few broken bones was better than castration, he jumped out of the window after the boulder. As he plummeted downward he saw a large sign on the ground that read, “Chinese Torture 3: Right testicle tied to bedpost.”
So far only some websites we run have been secured by an internal generated certificate which for everybody else caused a certificate error unless you imported the Certificate Authority that issued them somewhere. Now we’ve replaced it with a commercial certificate (wildcard version) to cover all the current websites and anything else we want to build or test in the future. Currently all sites will run with HTTPS, however it is not yet enforced, we will do this at a later stage. Both our blogs still can still start with HTTP however as soon as you go further it will go over into HTTPS, however we still need to edit some articles as they have collected hardcoded paths instead of relative paths in their content. This needs to be fixed until it will only run on HTTPS. Once that happens then if you then enter HTTP it will simply translate that to HTTPS for you.
Update (Sep 15): There where problems with Mozilla Firefox (Desktop as well as Mobile) throwing an error as well as Android (incl. Chrome browser), but these where due to a problem with the certificate chain. I did not test with others. Automatic rewrite on both eugene.dullaard.nl as well as sunny.dullaard.nl towards HTTPS is working fine. If the above doesn’t get resolved I will most likely revert that change until there is time to look at it. So with exception of the homepage everything is now SSL enabled. The homepage I didn’t do yet as it contains the cartoon that has an external source and cannot be obtained via HTTPS. This would throw alerts in certain browsers and as there is nothing special on that page, I left it as is.
