3

So I'm setting up single-signon authentication for the organization I work for.

Our IT guy has setup an ADFS server, which is where we're getting our logon credentials from. He's using an in-house security certificate that wasn't originally created for this task. Now upon setup, I was getting an error "The remote certificate is invalid according to the validation procedure". So I've added the certificate to my dev machine as trusted root, and that exception went away. Good.

Now upon logon, we're getting a 'IDX10201: None of the the SecurityTokenHandlers could read the 'securityToken'' error. And then a list of 3rd party certificate handlers (w3.org, godaddy).

Now a lot of the solutions I've found online just say to set yourself up as a token handler, but that doesn't seem to be the ideal, nor the more secure solution.

So, I have a few questions. Will getting a 3rd party certificate resolve the token handler issue? The certificate we're using was issued to a specific server, not my dev machine, is that an issue as well? SSL is a brand new world to me, so explain it to me like I'm in 1st year.

EDIT:

So upon running openssl x509 -in <certificate file> -text, I'm getting an error:

11568:error:0906D06C:PEM routines:PEM_read_bio:no start line: crypto\pem\pem_lib.c:691:Expecting: TRUSTED CERTIFICATE

The IT guy told me yesterday that he's using a "wildcard certificate", but I can get more information if needed.

Scuba Steve
  • 231
  • 1
  • 8
  • 1
    It will be very useful to add how the certificate was generated (ask the IT guy) and/or what it actually contains (`openssl x509 -in -text` will tell you a good deal about it) – grochmal Oct 14 '16 at 19:01
  • Sure thing. Will edit. – Scuba Steve Oct 14 '16 at 19:13
  • New info up there. – Scuba Steve Oct 14 '16 at 19:24
  • Thought I solved this, but the IT guy reinstalled ADFS and the problem came back. We think it's setup properly over there now, and they have a properly signed certificate, and we're still getting the error. – Scuba Steve Oct 15 '16 at 21:00
  • You need to know what kind of certificate you're using. A *certificate* is simply: a public key signed by the private key plus *some data* also signed with this private key (and often signed by the private key of someone else to give credibility). Where *some data* can be anything, but it ensures that the owners of the private keys used ensured that that *some data* is what they gave you (was not tampered with). According to openssl is is not an x509 certificate (which is by far the most common certificate format used). – grochmal Oct 15 '16 at 21:49
  • 1
    Thanks for taking the time to write. So yeah it actually is an x509 certificate, but openSSl doesn't seem to like the files I'm feeding it for some reason. Yesterday we replaced his in-house certificate with a 3rd party issuer. Problem turned out to be that the Asp.Net authentication pipeline doesn't handle encrypted security tokens out of the box. I followed this guide: http://chris.59north.com/post/Manually-configuring-OWIN-WS-Federation-middleware-and-accepting-encrypted-tokens I've resolved the token errors (and created different ones), but I'm on the right track. – Scuba Steve Oct 15 '16 at 23:29

1 Answers1

1

Turns out that Asp.Net doesn't support encrypted tokens out of the box. DarksideCookie made a great guide on how to set it up manually.

http://chris.59north.com/post/Manually-configuring-OWIN-WS-Federation-middleware-and-accepting-encrypted-tokens

Scuba Steve
  • 231
  • 1
  • 8
  • This answer is depreciated with JWT 5x. I've asked Darksite to update his guide, but I don't yet have a solution for newer versions of JWT. He does recommend finding a middleware solution for supporting newer versions. – Scuba Steve Mar 24 '17 at 22:09