Is it possible to use Postman Monitors to check how many days the SSL certificate has left before it reaches its expiration date?
When creating a request in Postman it is possible to see a popup called "Network". It contains information such as TLS protocol, Cipher name, Issuer CN and most importantly Valid until.
Inspecting the pm. object in the Tests-tab and by reading through the documentation did not yield any apparent way to get this information programmatically.
Is there any trick to get the certificate in any way programmatically inside Postman? Either via another request, some variable or property that I didn't discover yet?
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'm using the site https://www.hurl.it/#top to make a POST HTTP request to the Poloniex Exchange API.
Note that I have generated my Sign by going to https://www.freeformatter.com/hmac-generator.html#ad-output putting my SECRET and API_KEY into the given fields, and choosing the SHA512 algorithm.
I have filled out the fields at https://www.hurl.it/#top with the following (All fields are verbatim other than API_KEY and SECRET for obvious reasons):
Destination
POST: https://poloniex.com/tradingApi
Headers
Key: API_KEY
Sign: SECRET
Parameters
nonce: 0001
command: returnBalances
I am then given the error:
{"error":"Invalid API key\/secret pair."}
What am I doing wrong? Am I not following the API requirements for an HTTP request verbatim? Also I am not looking for any libraries/programming languages to use. I am looking to make this work using this website or something similar, because once I do, I will have what I'm looking for.
Note that I have generated my Sign by going to https://www.freeformatter.com/hmac-generator.html#ad-output putting my SECRET and API_KEY into the given fields, and choosing the SHA512 algorithm.
Api & secret are very sensitive data, so take care to:
- Never share your api key and secret on a tier website. (it could be store and be reuse)
- Never send a request containing your api key and secret in clear. (it could be intercepted by a MIM attack and/or your ISP and/or DPI)
Finally :
You may compute yourself (locally) the signature using a PHP wrapper recommended on the Poloniex Api documentation page
I am using Runscope only for a short time now however it seems pretty straight forward. I have had no problem with other APIs, however for this current one I am having problems.
The error I am getting is the following:
Error contacting host SSL: certificate is valid for *.hostgator.com,
hostgator.com, not NflArrest.com To turn off SSL verification for
this test, change your test's behavior settings, see
https://www.runscope.com/docs/api-testing/behaviors for more details
From the documentation I read here:
SSL Certificate Verification
By default, Runscope will only relay responses if the SSL certificate from the upstream API provider is valid and trusted. To bypass this protection (for instance if you're using a self-signed certificate) on a per-bucket basis, select Bucket Settings in the left sidebar and deselect the option to 'Verify SSL Certificates'.
I have done that so to my knowledge it should work. However I still get the same error. The API documentation I am using can be found here.
Test's don't use the bucket setting, that's just for Gateway URLs/Traffic Inspector. To disable SSL verification in your test, expand the "Environment" section at the top of the test editor, select "Behaviors" and untoggle it there.
While I was reading about interaction with Amazon S3, I came to know that request authentication with Amazon AWS is done in 2 ways
HTTP Authorization:
Using the HTTP Authorization header is the most common method of providing authentication information
Query string parameters:
Using query parameters to authenticate requests is useful when you want to express a request entirely in a URL. This method is also referred as presigning a URL.
The question is in which situation should I prefer one method over the other. Do these two authentication methods have their own advantages and disadvantages? As a developer, by using query string parameters method I can presign the URL which enables the end users to temporarily access the Amazon S3 resources by entering the presigned URL in the web browser. Can I use HTTP Authorization method to achieve the same thing? If so which method is better to use and what are their respective limitations?
Can I use HTTP Authorization method to achieve the same thing?
Sometimes. The key difference is that, as a developer, you don't always have enough control over the user agent to inject a header. The most obvious example of this is a simple GET request launched by a web browser in response to the user clicking a link. In that situation, you don't have the a ability to inject an Authorization: header for the browser to send ... so pre-signing the URL is all you can do.
Importantly, there's no information in a signed URL that is considered sensitive, so there's no particularly strong motivation to use the header instead of a signed URL. Your AWS Access Key ID is not secret, and your AWS Secret can't be derived from the other elements and the signature in a computationally-feasible time frame, particularly if you use Signature Version 4, which you should. Signature Version 2 is not officially deprecated in older regions, but newer S3 never supported it and likely never will.
When you do control the user agent, such as in back-end server code, adding the header may be preferable, because you don't need to do any manipulation of the URL string you already have in-hand.
The overview in the first AWS page says what the difference is:
Except for POST requests and requests that are signed by using query parameters, all Amazon S3 bucket operations and object operations use the Authorization request header to provide authentication information.
Basically a POST is used for HTML forms (discussed at length in the Mozilla page). You would use forms whenever the request involves passing data to the remote server, versus just checking status. As noted in HTML method Attribute (W3Schools),
Never use GET to send sensitive data! (will be visible in the URL)
as distinguished from POST:
Appends form-data inside the body of the HTTP request (data is not shown is in URL)