Im coding for SNOM handsets
Basically I do a $post to a hashed URL as below
$post("https://8a4a1db6256ec8e310193a166d6d1f84#192.168.1.110/command.htm?number=01233456789")
Returns
net::ERR_CERT_INVALID
If I call HTTP the phone dials fine, BUT if run from app then the windows throws the security issue as AJAX call has to be secure. Tags are set to off, client is set and defined, works if I post an HTTP request .
I have created my own DER cert as well and uploaded that to the phone and I tried to register this certificate with the browser but no avail.
I have in chrome dropped down the cert and clicked it to ALWAYS TRUST but it keeps falling back to INVALID
There are several certificats on the phone just cant get a browser to trust them ?
Any advice or point of where to read up on how to register the server cert with my users browsers ?
Ok so anyone working their way through this issue there's a few steps you need to take
1 - set http client username and passwords
2 - in the phone interface ensure connection types are set to hhtp AND https
3 - set hidden tags to false
4 - set authentication scheme to DIGEST then MD5 the password int eh post
5 - Download ca.cert from http://downloads.snom.net/documentation/ca.crt
6 - install the cert on your local computer THEN set the cert to ALWAYS TRUSTED
7 - figure out a way around CORS...
Related
I have a POST request step in soapUI that works successfully with my SSL certificate.
It uses the certificate (key may be more accurate) that I saved in soapUI's application configuration settings.
What I want to do is make this request as some test user Bob. Bob has a DN in the system under test.
How to do this?
Adding a header to the request had no effect. I tried X-ProxiedEntitiesChain.
Do I need to remove the key from the settings in order for soapUI to use the header I supply?
Can anyone shet some light on how I can debug the matching of certificates configured in Postman?
Problem:
I’m trying to connect to a REST service using a SSL client certificate. I configured it in the settings tab the same way as in set-and-view-ssl-certificates-with-postman
When checking the console I don’t see the certificate being sent and get failure:c:\projects\electron\vendor\node\deps\openssl\openssl\ssl\s3_pkt.c:1494:SSL alert number 40
Context:
Postman v 6.4.2 running on windows 10
(for security reasons some information below replaced by dummy info)
Using the same certificate/key/password I can setup a connection using openssl. (checked for validity of certificates, TSL v1.1 and v1.2 supported, no SNI issues)
The server certificate is signed by a trusted CA (I tested with both --SSL certificate verification-- on and off )
In the Postman console I dont see the certifciate being sent.
---- [console output] ----
GET https://somehost:443/somepath?someparameter=9076443&somedate=2017-02-17T00:00:00.000
Error: write EPROTO 101057795:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:c:\projects\electron\vendor\node\deps\openssl\openssl\ssl\s3_pkt.c:1494:SSL alert number 40 101057795:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:c:\projects\electron\vendor\node\deps\openssl\openssl\ssl\s3_pkt.c:659:
Request Headers:
appid:“42”
cache-control:“no-cache”
ipaddress:“192.68.1.1”
postman-token:“some-token”
role:“Applicatie”
userid:“6x9”
---- [end console output] ----
image of certificate configuration
I matched, matched and rematched the hostname
A search on the interweb did not learn me anything I did not try yet…
Questions
Is there any debug option that will show the way the certificates are matched
is there any way I can force postman to pick a configured certificate
any other ideas on how to proceed on this problem
any help appreciated
Additional info
Monitoring with wireshark shows no certificate is sent.
(Postman console did not show a certificate being sent. I assume from examples that it will log which certificates it will/does send for a given request)
snippet wireshark output
Postman app in chrome
it does work from chrome, using the chrome keystore
Using the pk12 form of the same key (original postman request uses the .cer form) imported into the chrome keystore, the requests work.
Chrome app will not do
Obvious question is: “why not keep using the chrome app”
because its depricated and we use the newer 6.x test functions not supported in version 5.x
Question posted on Postman help forum with no answer about a week ago:
OP on postman helpforum
Additional additional info
It works on newman
I had same issue when I typed path to CRT and KEY files instead of using file dialog.
Just click Choose File button instead of pasting file path when adding certificate.
If you can download postman app then there is an option under preference/certificate and under there is an option 'Client Certificate'.
You need to provide both .cert and .key file into respective section, provide host name and key password if any. Click "save". next time you send a request matching hostname , postman app will send the certificate along with the way. You can validate in console output.
I am trying to implement the Apache authentication through PKI digital certificates stored on token / smart card.
I'm using XAMPP 5.6.8.0-VC11 on a Windows 7 computer.
Following what I found searching the internet, I uncommented the following settings httpd-ssl.conf file in the Apache configuration:
SSLVerifyClient require
SSLVerifyDepth 10
From there, access to https: // localhost, the browser (IE 11, Chrome 43 and FF 38) display the digital certificate of the screen (use an e-CPF in standard ICP-Brazil, stored in token) and requests the password.
After entering the password and press ENTER, the behavior in browsers is as follows:
In IE, I is shown a page with the message "This page can not be displayed".
In FF, is loading the page indefinitely.
In Chrome, you see the message "Authentication based on certificate failed" ERR_BAD_SSL_CLIENT_AUTH_CERT and clicking on "details" appears:
"This server requires a certificate for authentication and did not accept the one sent by the browser. Your certificate may have expired or the server does not trust the issuer. Try again with a different certificate, if you have one, or you must obtain a certificate valid from somewhere else. "
Already tested several additional settings I found on the internet, but nothing works.
I have also changed the Windows Internet options regarding SSL and TSL, also successful.
I would like to figure out how to implement authentication with digital certificates for a more secure login system that esté in development.
Has anyone experienced this or know how to solve the issue?
When I was working on facebook.com to recorded the login process using jmeter, then I came across the following error message. what should we do in such condition in order to surpass this step and directly gets login into the facebook application using the proxy server setting for the recording purpose.
The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issue)
As per Recording HTTPS Traffic with JMeter's Proxy Server I believe that it'll be quite enough to clear your browser history.
While debugging, we observe following behavior:
1) When trying to get encryption key from server then error on both (iOS or Android) platform
response [https://xxxx.xxxx.com:443/worklight/apps/services/random]
success: Exception thrown by application class
'com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity():685'
SESN0008E: A user authenticated as anonymous has
attempted to access a session owned by user:NewRealm/CN=test
user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
2) When trying to read a stored value error on android is [Logcat]
Android Message: Uncaught 9 at
file:///data/data/com.xxxx.xxxxapp/files/www/default/wlclient/js/encryptedcache.js:63
Where try to call WL.EncryptedCache.read
Worklight version used is 5.0.5 Consumer Edition (with Oracle 11i) on
Windows 2008 R2
WebSphere Liberty profile
Worklight server is sitting behind IBM Datapower XI52. All SSL calls to the server are going via DP.
Authenticator - WebSphereFormBasedAuthenticator & LoginModule - WASLTPAModule
The following is not really an answer, since I'm not familiar with authentication (LTPA, FormBasedAuth, Data Power, etc.)... just a couple of comments that could help you debug/isolate the issue.
Looks like a problem with authentication:
A user authenticated as anonymous has attempted to access a session
owned by user:NewRealm/CN=test user,OU=Temporary
Users,OU=Acc,DC=xxxx,DC=com.
Not with the Encrypted Offline Cache (EOC).
EOC will try to get a random token calling the following function:
WL.EncryptedCache.secureRandom(function (data) {
console.log(data);
});
It should output something like this:
response [/apps/services/random] success: 9053bdcfd902aac3dfb59a9874c9cf55223b7d17
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view the functions source code typing the following in a JS console:
WL.EncryptedCache.secureRandom
If you're using Google Chrome developer tools there's a checkbox for Log XMLHttpRequests when you click on the gear icon > General > Console.
You can also try to request the URL directly. Assuming the host is localhost, port is 10080 and project name is wlproj:
http://localhost:10080/wlproj/apps/services/random
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view HTTP traffic with Wireshark or Charles Proxy.
I imagine this will fix the EOC issue for you, if you don't mind generating the random token locally (less security, AFAIK):
WL.EncryptedCache.secureRandom = function(callback){callback(Math.random()+"")}
For example:
Notice it never goes to the server, everything is done locally.
A user authenticated as anonymous has attempted to access a session owned by user:NewRealm/CN=test user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
This usually means that there is a conflict with the session sent by the user (the session cookie) belongs to a user (in this case), but the LTPA token sent as a cookie was not sent or was not valid. There could be a few causes of this. This best way is to do a trace between datapower and the worklight server to make sure an LTPA token is even being sent to the worklight server. If it is, verify all of the LTPA requirements are met (synchronized time, same private key on both machines).