Using Postman I access 2 different URLs that belong to the same domain:
A: https://www.example.com
B: https://other.example.com
A responds fine, but B responds with Warning: Certificate has expired. I am wondering why that is so?
Both A and B respond with same certifacate which expires in 2 months.
Subject looks like this:
commonName: "example.com"
alternativeNames: "DNS:example.com, DNS:*.example.com"
Related
I have a site with two https servers. One (frontend) serves up a UI made of static pages. The other (backend) serves up a microservice. Both of them happen to be using the same (test) X509 certificate to identify themselves. Individually, I can connect to them both over https requiring the client certificate "tester".
We were hiding CORS issues until now by going through an nginx setup that makes the frontend and backend appear that they are same Origin. I have implemented the headers 'Access-Control-Allow-Origin', 'Access-Control-Allow-Credentials' for all requests; with methods, headers for preflight check requests (OPTIONS).
In Chrome, cross-site like this works just fine. I can see that front-end URLs and backend URLs are different sites. I see the OPTIONS requests being made before backend requests are made.
Even though Chrome doesn't seem to need it, I did find the xmlhttprequest object that will be used to perform the request and did a xhr.withCredentials = true on it, because that seems to be what fetch.js does under the hood when it gets "credentials":"include". I noticed that there is an xhr.setRequestHeader function available that I might need to use to make Firefox happy.
Firefox behaves identically for the UI calls. But for all backend calls, I get a 405. When it does this, there is no network connection being made to the server. The browser just decided that this is a 405 without executing any https request. Even though this is different behavior from Chrome, it kind of makes sense. Both the front-end UI and backend service need a client certificate to be chosen. I chose the certificate "tester" when I connected to the UI. When it goes to make a backend request, it could assume that the same client certificate should be used to reach the back-end. But maybe it assumes that it could be different, and there is something else I need to tell Firefox.
Is anybody here using CORS in combination with 2 way SSL certificates like this, and had this Firefox problem and fixed it somewhere. I suspect that it's not a server-side fix, but something that the client needs to do.
Edit: see the answer here: https://stackoverflow.com/a/74744206/537554
I haven't actually tested this using client certificates, but I seem to recall that Firefox will not send credentials if Access-Control-Allow-Origin is set to the * wildcard instead of an actual domain. See this page on MDN.
Also there's an issue with Firefox sending a CORS request to a server that expects the client certificate to be presented in the TLS handshake. Basically, Firefox will not send the certificate during the preflight, creating a chicken and the egg problem. See this bug on bugzilla.
When using CORS with credentials (basic auth, cookies, client certificate, etc.):
Access-Control-Allow-Credentials must be true
Access-Control-Allow-Origin must not be *
Access-Control-Allow-Origin must not be multi-value (neither duplicated nor comma-delimited)
Access-Control-Allow-Origin must be set to exactly the value from the request's Origin header in order for the request to work (either hard-coded that way or if it passes a whitelist of allowed values)
The preflight OPTIONS request must not require credentials (including the client certificate). Part of the purpose of the preflight is to ask what is allowed in a CORS request, and therefore sending credentials before knowing if they are allowed is incorrect.
The preflight OPTIONS request must return a 200-level response, generally 204
Note: For Access-Control-Allow-Origin, you may want to consider allowing the value null since redirect chains (like the ones typically used for OAuth) can cause that Origin value in a request from a browser.
I'm following the steps here . I've got the authorization code in the browser, but get a:
** Access error: protocol error: "Server error: HTTP/1.0 400 Bad Request"
when I generate my request to try and obtain my token. I changed the target to http so that I could trace the http request in wireshark and I get this with line wrap added:
POST /oauth2/v3/token HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: www.googleapis.com
User-Agent: REBOL
Content-Type: application/x-www-form-urlencoded
Content-Length: 251
code=url-encoded-my-authorisation-code&
client_id=my-client-id.apps.googleusercontent.com&
client_secret=my-client-secret&
redirect_uri=urn-blah-blah&
grant_type=authorization_code
which looks good to me.
When I use the http instead, I get this message
{"error":"internal_failure","error_description":"SSL is required to perform this operation."}
but unfortunately it's not telling me if my request is otherwise off to help me with the ssl request.
PS: I've progressed further. I removed the URL encoding from the redirect_uri and now I get an invalid_grant error. Before this it complained of a missing scheme for the redirect_uri.
On one occasion I did success in obtaining an access token but I've not been able to reproduce this. I saw my app listed in those I've granted access tokens. I removed my app and tried to grant again but keep failing.
My clock is correct so that's not the issue. The oauth2 playground works fine and as far as i can tell I'm doing the same but without success.
Mine is an installed app so I can't provide my credentials to the playground as a way to trust their redirect_uri is not provided and I get an error.
It seems that there is a limit on refresh_tokens and although removing the app from those with authority to access my calendar did not work, deleting my project from the https://console.developers.google.com/ and recreating them worked. My code then ran successfully without any changes.
Try change url to get info about token from Google use https://www.googleapis.com/oauth2/v3/tokeninfo?access_token={accessToken}
Be careful vith version api
I am trying to build a Ruby Daemon service to access the Office 365 rest API. It was recently made possible to do this via the OAuth 'client_credentials' flow, as detailed in this blog post: https://learn.microsoft.com/en-us/archive/blogs/exchangedev/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow
I am struggling to generate a valid access token. The token endpoint returns me a JWT however when using this token I received a 401 with this message:
The access token is acquired using an authentication method that is too weak to allow access for this application. Presented auth strength was 1, required is 2
I understand that the client_credentials flow requires you to present a X.509 cert, unfortunately all the examples in the blog post are for C#.
I am using a generated self signed cert and private key to do a client assertion when requesting the token. I followed the steps in the blog post to generate the cert and update the manifest to use this cert.
This is the ruby code for reference:
def request_token
uri = URI.parse("https://login.windows.net/== TENANT-ID ==/oauth2/token?api-version=1.0")
https = Net::HTTP.new(uri.host, uri.port)
req = Net::HTTP::Post.new(uri.request_uri)
req.set_form_data(
:grant_type => 'client_credentials',
:redirect_uri => 'http://spready.dev',
:resource => 'https://outlook.office365.com/',
:client_id => '== Client ID ==',
:client_secret => '== Client secret =='
)
https.use_ssl = true
https.cert = client_cert
https.key = client_key
https.verify_mode = OpenSSL::SSL::VERIFY_PEER
resp = https.start { |cx| cx.request(req) }
#access_token = JSON.parse(resp.body)
end
Obviously I have removed certain bits of information for security. Even though it is ruby you can see I am using my cert to validate the client using an SSL connection.
Here's some more infomation on the error:
"x-ms-diagnostics" => "2000010;
reason=\"The access token is acquired using an authentication method that is too weak to allow access for this application. Presented auth strength was 1, required is 2.\";
error_category=\"insufficient_auth_strength\"",
"x-diaginfo"=>"AM3PR01MB0662",
"x-beserver"=>"AM3PR01MB0662"
Any help would be appreciate.
Edit
For others looking to do something similar in Ruby here's a Gist of the code I use: https://gist.github.com/NGMarmaduke/a088943edbe4e703129d
The example uses a Rails environment but it should be fairly easy to strip out the Rails specific bits.
Remember to replace YOUR CLIENT ID, TENANT_ID and CERT_THUMBPRINT with the correct values and point the cert path and client key methods to the right file path.
Then you can do something like this:
mailbox = OfficeAPI.new("nick#test.com")
messages = mailbox.request_messages
Instead of a client_secret in your request body, you need a client_assertion. This is a bit more complex, but it's the reason you need that certificate.
Basically you need to build a JSON Web Token and sign it with your certificate using a SHA256 hash. The token is going to look something like this:
Header:
{
"alg": "RS256",
"x5t": "..." // THUMBPRINT of Cert
}
Payload:
{
"aud": "https:\\/\\/login.windows.net\\/<The logged in user's tenant ID>\\/oauth2\\/token",
"exp": 1423168488,
"iss": "YOUR CLIENT ID",
"jti": "SOME GUID YOU ASSIGN",
"nbf": 1423167888,
"sub": "YOUR CLIENT ID"
}
If you're still with me, you now need to base64-encode both pieces (separately), then concatenate them with a '.'. So now you should have:
base64_header.base64_payload
Now you take that string and sign it with your certificate, using a SHA256 hash. Then base64-encode the result of that, url-encode it, then append to the string, so now you have:
base64_header.base64_payload.base64_signature
Finally, include this in your POST to the token endpoint as the client_assertion parameter, and also include a client_assertion_type parameter set to "urn:ietf:params:oauth:client-assertion-type:jwt-bearer":
req.set_form_data(
:grant_type => 'client_credentials',
:redirect_uri => 'http://spready.dev',
:resource => 'https://outlook.office365.com/',
:client_id => '== Client ID ==',
:client_assertion_type => 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
:client_assertion => 'base64_header.base64_payload.base64_signature'
)
I hope that helps! This is all based on my research into how ADAL does it, and I haven't tested it myself in Ruby.
I just managed to get this working, so I thought I'd throw one more piece of advice into the mix. All the instruction articles out there say that you should add your certificate to the manifest file. I had trouble with that, but here is what I did that finally made it work:
In Azure, go to Settings > Management Certificates
Upload the public key as a .cer file (google around if you don't know how to convert it). This should be a binary file that your text editor barfs on.
Now that it's uploaded, Microsoft will give you the thumbprint. It's in the "Thumbprint" column. But, it's in hex, not base64. So, convert it like this:
# Hint: use your actual thumbprint, not this fake one
echo '5292850026FADB09700E7D6C1BCB1CD1F3270BCC' | xxd -r -p | base64
Finally, use this base64 encoded thumbprint as the value for x5t in the JSON header.
I added a function in HomeController on the git to demo how to request an access token by hand using client assertion w/o ADAL. It might be easier to port using this: https://github.com/mattleib/o365api-as-apponly-webapp/commit/12d5b6dc66055625683020576139f5771e6059e1
Just some additions: The audience claim in the assertion is the same as the endpoint you address with the token request. As Jason correctly identified, this is the token endpoint of AAD: https://login.windows.net/{the tenant you want an app token for}/oauth2/token. Also the nbf and exp are the time you created the assertion in unix epoche time, e.g. in .net you would do something like "WebConvert.EpocTime(DateTime.UtcNow)". For "not before" (nbf) maybe subtract a buffer for clock skew, e.g. 5 minutes; and for expires in (exp) add some time, e.g. 15 minutes (so the assertion remains valid for that time).
Here is a fiddler trace of a token request (raw):
POST https://login.windows.net/0e49ef1f-ca07-45f1-b4c0-ac9409d3e576/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
client-request-id: a8108f88-275b-424d-ac28-f675aabe548e
return-client-request-id: true
x-client-SKU: .NET
x-client-Ver: 2.12.0.0
x-client-CPU: x64
x-client-OS: Microsoft Windows NT 6.2.9200.0
Host: login.windows.net
Content-Length: 983
Expect: 100-continue
Connection: Keep-Alive
resource=https%3A%2F%2Fgraph.windows.net%2F&client_id=f17bb8a5-2bef-4ad5-a83f-cd7113449fc2&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6ImY4S2JVY0xtMnItS2s4b1Z3ZVZYTFU0NzhJcyJ9.eyJhdWQiOiJodHRwczpcL1wvbG9naW4ud2luZG93cy5uZXRcLzBlNDllZjFmLWNhMDctNDVmMS1iNGMwLWFjOTQwOWQzZTU3Nlwvb2F1dGgyXC90b2tlbiIsImV4cCI6MTQyMjk4NDMzNSwiaXNzIjoiZjE3YmI4YTUtMmJlZi00YWQ1LWE4M2YtY2Q3MTEzNDQ5ZmMyIiwianRpIjoiZTI3OTA5YTctZGYwMC00NjBhLTlmZjctOGZkNDExOWVmNTYzIiwibmJmIjoxNDIyOTgzNzM1LCJzdWIiOiJmMTdiYjhhNS0yYmVmLTRhZDUtYTgzZi1jZDcxMTM0NDlmYzIifQ.g9bo4-lxpNJ4kEOMuQxODU-5iakwSVIzyRQEPLdbpuNn_XD4lcvt2yBIWT12EQaUVKkMyqFrDiIh4Oav565-Po7HfhmSPF3URXVj8Kx5lx17Zh0nWiaNkRXEi1vhwswsfjm1o-8B8LGUJTtT6JXTognrueuSL1aEE_-4qSG1y74aoc949Un1pQCjwuBtao4vs4CPJLu9Y9mVbirVRRtiIfxkUMmzf6yfMtuhugoGmrvUYntUo4x6N2fu4LxGjuIs7czyrMMAmDRo-XK4sAhDo5uof10HKb8ETEU8mhObwNZcz86MYHWbZm3Z_HDOwzC9kA_tp6hWqmlJ3c-gLg5VXA&grant_type=client_credentials
Hope this helps!
Good luck!
Matthias
What we have?
Client : win8, ie11, logged in into system using domain credentials.
Server : 3 tomcat7 nodes run beyond apache 2.2.22. application uses waffle library to authenticate windows users who are logged in into domain in sso manner.
Application uses spring security and the main thing regarding this topic is that filter that handles login via form comes before filter that handles authentication headers.
NegotiateSecurityFilterProvider supports only Negotiate protocol, not NTLM
What we do?
Go into application via direct link : https://app.domain.com/app_name/subordinates.do.
It is ok, we are bearing valid kerberos header (it is good and big one kerberos token which fiddler describes as 'Authorization Header (Negotiate) appears to contain a kerberos ticket' ^^) and waffle on application side passes us inside with kerberos reply.
Logout.
Login via form on login page: we make post request with user_name and password, again we bearing same kerberos token. Application uses user_name and password to login us with help of waffle WindowsAuthenticationProvider. Here we get authenticate before we rich NegotiateSecurityFilter, so there is no any kerberos header within reply from server. Anyway everything is ok.
Now we are log into MS account via OS. And magic happens.
When trying to login via direct link we get 'The handle specified is invalid' error on login page as SPRING_SECURITY_LAST_EXCEPTION constant. my guess here is that we send some kind of invalid authorization header
And when trying to login via form we get 'The parameter is incorrect'. here i think we send ntlm type 1 POST request with empty body but we still have invalid header so application does not recognize it and does not sent 401 reply and thereafter waffle sends null name to AD and here error comes (just guess)
BUT when I turn fiddler on to see what is really happened then everything begins to work fine as before login into MS account. Ok, to figure out what header are sent to the server I used some code inside cmd file:
UDPATED add code and output
var cookieContainer = new CookieContainer();
var authRequest = (HttpWebRequest) WebRequest.Create("https://app.domain.com/app_name/home.do");
var credentials = CredentialCache.DefaultNetworkCredentials;
authRequest.Credentials = credentials;
authRequest.CookieContainer = cookieContainer;
authRequest.AllowAutoRedirect = false;
var authResponse = (HttpWebResponse)authRequest.GetResponse();
Console.WriteLine("Request headers:");
foreach (string header in authRequest.Headers.AllKeys) {
Console.WriteLine("\t{0}: {1}", header, authRequest.Headers.Get(header));
}
Console.WriteLine("\nResponse: {0} {1}", (int)authResponse.StatusCode, authResponse.StatusDescription);
Console.WriteLine("Response headers:");
foreach (string header in authResponse.Headers)
Console.WriteLine("\t{0}: {1}", header, authResponse.GetResponseHeader(header));
foreach (var cookie in cookieContainer.GetCookies(new Uri("https://app.domain.com/app_name/")))
Console.WriteLine("Received cookie: {0}", cookie);
Console.WriteLine("\nPress ENTER to exit");
Console.ReadLine();
Here what I get:
Request headers:
Authorization: Negotiate oTMwMaADCgEBoioEKE5UTE1TU1AAAQAAAJeCCOIAAAAAAAAAAAAAAAAAAAAABgOAJQAAAA8=
Host: {host}
Cookie: JSESSIONID={sessionId}
Response: 302 Found
Response headers:
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/ plain; charset=UTF-8
Date: Tue, 04 Feb 2014 11:44:15 GMT
Location: https://app.domain.com/app_name/login.do?error_code=1
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8t mod_jk/1.2.37
Received cookie: JSESSIONID={sessionId}
It is definitely much smaller header than kerberos one what fiddler sees when authentication works.
So questions are:
1. Why does loging into MS account affect what headers are sent to server?
2. Why it begins to work when fiddler on?
3. What type of this header : Negotiate oTMwMaADCgEBoioEKE5UTE1TU1AAAQAAAJeCCOIAAAAAAAAAAAAAAAAAAAAABgOAJQAAAA8= and how should it be handled by server?
UPDATE 17 March 2014:
wireshark capture shows KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN error after tgs request, server mentioned - machine name with apache.
After investigation with support team we found out that special user which is used to run tomcat servers on different nodes didn't have spn for domain name of machine with apache (it had spn for resource domain name but not for current machine). After spn was added problem disappeared.
After decoding oTMwMaADCgEBoioEKE5UTE1TU1AAAQAAAJeCCOIAAAAAAAAAAAAAAAAAAAAABgOAJQAAAA8= we can see that it contains NTLMSSP (a new version).
Check browsers configuration:
In Internet Explorer: webpage should be in "Local intranet" zone (in a zone in which user is logged automatically) and that IWA, Integrated Windows Authentication is enabled.
If that's not the case, please take a look in Wireshark for dns and kerberos packets.
Check DNS:
IE uses dns to resolve webserver address into principal name. CNAME address is resolved into A address. If not found, IE will not ask for Kerberos service ticket at all (and will fallback to NTLM).
Check SPNs:
When Active Directory can't find requested principal (or there or two, or more). Then IE falls back into NTLM.
I have a web application that uses jQuery.ajax to perform a request to another host (right now actually the same because I'm using different ports of "localhost"). The server then returns a cookie.
The cookie value in the HTTP response as shown in Chrome's Dev Tools is
Set-Cookie: MyUserSession=JxQoyzYm1VfESmuh-v22wyiyLREyOkuQWauziTrimjKo=;expires=Sun, 10 Feb 2013 22:08:47 GMT;path=/api/rest/
and so has an expiry of 4 hours in the future.
However, the cookie does not get stored and sent with subsequent requests (tested in both Chrome and Firefox). I first thought it must be "10-Feb-2013" instead of "10 Feb 2013" but that doesn't make a difference. Chrome also shows "Expires" as "Invalid date" on the cookies tab of the response, but that might as well be a Dev Tools bug.
Any ideas?
I think I found the solution. Since during development, my server is at "localhost:30002" and my web app at "localhost:8003", they are considered different hosts regarding CORS. Therefore, all my requests to the server are covered by CORS security rules, especially Requests with credentials. "Credentials" include cookies as noted on that link, so the returned cookie was not accepted because I did not pass
xhrFields: {
withCredentials: true
}
to jQuery's $.ajax function. I also have to pass that option to subsequent CORS requests in order to send the cookie.
I added the header Access-Control-Allow-Credentials: true on the server side and changed the Access-Control-Allow-Origin header from wildcard to http://localhost:8003 (port number is significant!). That solution now works for me and the cookie gets stored.
After struggling with a similar scenario (no CORS) for hours, I found out another potential reason: be sure to explicitly set the path for the cookie.
My front-end app was making a call to HOST_URL/api/members/login, and this was returning the right Set-Cookie header, with no path.
I could see the cookie under Response Cookies in Chrome DevTools, but subsequent requests were not including it. Went to chrome://settings/cookies, and the cookie was there, but the path was /api/members.
Specifying root path when setting the cookie at server-side fixed the issue.
where do you get the date from?
if you add it manually try making it failproof
var exdays = 3; //3 days valid as an example
var exdate=new Date();
exdate.setDate(exdate.getDate() + exdays);
//Now set the cookie to said exdate
document.cookie = "MyUserSession =" + escape(JxQoyzYm1VfESmuh-v22wyiyLREyOkuQWauziTrimjKo=)+"; expires="+exdate.toUTCString());