I want to create a helpdesk project following this great tutorial : http://blog.jetbrains.com/youtrack/2014/02/using-youtrack-as-a-help-desk/
I want to set the parameters of my mailbox using a Gmail adress but I don't know how to obtain a SSL key from Gmail.
Without it, I have "Connection timed out" error. I know where to add the SSL key in Youtrack, but I need a file (JKS or PKCS12 format).
My settings:
Protocol:IMAPS
Host:imap.gmail.com
Port:993
Login:mylogin
Password:mypassword
Select SSL key: nothing
Connection timeout:60
Socket timeout:60
Please help :)
Here how to obtain Gmail trusted root keys (from Google PKI FAQ):
Google may decide to have its intermediate signed by another root at any point in time, so you should have an update mechanism in place for the trusted roots you ship with your product. If you are developing code intended to connect to a Google property, we recommend you include a wide set of trustworthy roots. We made an example available as a PEM file here.
PEM file provided can be manually converted to PKCS12 with, for instance, OpenSSL tool.
I suspect, however, that installing a cert won't solve the issue. "Select SSL key" likely stands for client (i.e. YouTrack) certificate, which is not required by Gmail. Please check the following:
If IMAP is enabled in your GMail account
this recipe to make sure Gmail is not blocking new client application explicitly
Related
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 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.
I have been asked to update an old project done in objective-c.
I'm having this issue with my distribution provisioning profile. It goes like this
Provisioning profile "XXXXXX" doesn't include signing certificate
"iPhone Distribution: XXXXXXXXXX (XXXXXXXXXX)".
The thing is I can see the certificate "iPhone Distribution: XXXXXXXXXX (XXXXXXXXXX)" in my keychain. But there are 2 of them. One has a private key and the other one doesn't and both have a different expiry date. When I checked the developer account, the distribution provisioning profile is signed with certificate that doesn't have a private key (the expiry date of the certificate shown on developer account is that of the one without private key)
What is causing this issue?
How can I fix it?
What if I can't get the private key from the older machine(as that machine is no more usable)
I tried deleting one of the certificates, and also automatically manage signing. Both didn't work.
Please help.
The problem is that the only valid provisioning profile you have tied to the distribution certificate for which you do not have the private key. Without the private key, it is not a valid signing identity, so Xcode won't use it.
To fix this, You will need to create a new private key / distribution certificate, and then create a new distribution profile using the newly created certificate. You can find instructions, starting with creating the cert signing request, here.
See 2 above. Without the key, you can't use the existing certificate. If you are needing to build from multiple Macs, you need to set up a sharing mechanism to provide the private key to any other Macs that will be downloading and using the certs / profiles from the Apple's site. I would also back up the private key so that you won't run into this in the future if something happens to your build Mac. Also, when the cert expires, it is helpful to keep the .csr file from answer 2 above. This means you can use the same private key for the new cert when your distribution cert expires.
Make sure you have selected right Code Signing identity.
In my case I had selected Distribution instead of Developer
My problem:
I need, basic authentication over HTTP (client can't afford HTTPS). So I don't worry if communication is not encrypted. I just want to prevent some user from sniffing and using the password (site only used to upload photos and those photos are public.).
Toolbox of what I have at my disposal:
Javascript
PHP
Sha512.js
The SHA algorithm is the same in both PHP and JS:
The proof:(?)
<?php
$password= "password";
echo hash('sha512',$password);
//outputs: b109f3bbbc244eb82441917ed06d618b9008dd09b3befd1b5e07394c706a8bb980b1d7785e5976ec049b46df5f1326af5a2ea6d103fd07c95385ffab0cacbc86
?>
While in JS (all my files are encoded in utf8)
document.getElementById("hiddenField").value
= JS.sha512("password");
//outputs b109f3bbbc244eb82441917ed06d618b9008dd09b3befd1b5e07394c706a8bb980b1d7785e5976ec049b46df5f1326af5a2ea6d103fd07c95385ffab0cacbc86
However I cannot simply send the same hash on every connection, else anyone can sniff it and send it to connect.
So my idea was to use password_hash() function as salt generator.
The salt is public, the hash of (password+salt) is public, but password is private and never sent as clear text: the server will compute (hopefully) the same hash as the one in JS from the client and verify that both hashes match.
The problem is that regardless of what I do, I'm unable to get the same output when I hash the output of that function(password_hash). It seems to be something related to encoding.
I want to use password_hash() because it already keeps into account a lot of security stuff:
Javascript:
document.getElementById("hiddenField").value
= JS.sha512("password" + document.getElementById("publicToken").value);
I put the "password_hash" content into another hidden form field that I call "publicToken". Regardless of what I do I'm unable to get the hash match:
<?php
$salt = ut8_encode(password_hash("another_password")); //doesn't work either
In the end, what do I have to do to get a correctly encoded salt?
<?php
$salt = //... one time usage salt.. but what to put here?
I realize your client cannot afford a standard HTTPS certificate, but honestly, even a free SSL certificate is likely to be far better than what ever you can concoct here.
In this situation, all you are doing is making the browser-side hash the user's password, and all one has to do to get in is send a matching hash. If you decide to do this, you definitely need to hash the password again on the server side, but it is still no replacement for SSL.
More on it here: https://crackstation.net/hashing-security.htm
Without public key cryptography and a way to verify the identity of the server (in other words, HTTPS), the unfortunate truth is that there is simply no way to secure the communication to an acceptable level. I would not even advise trying, for fear of getting a false sense of security. No matter how much you hash and salt, it will only be minimally better than sending the plaintext password and trivial to break.
If your client cannot afford a certificate, I would recommend taking a look at StartSSL. Their basic level certificates are completely free; I believe they're valid for 1 year with unlimited renewal.
Another project worth looking at is Let's Encrypt. They've trying to make the process of getting a certificate much simpler and more accessible, so they've developed a way to completely automate the process of issuing (free) certificates. The service is not live yet, unfortunately; they plan to start issuing certificates this summer. Quoting their page:
Anyone who has gone through the trouble of setting up a secure website
knows what a hassle getting a certificate can be. Let’s Encrypt
automates away all this pain and lets site operators turn on HTTPS
with a single click or shell command.
When Let’s Encrypt launches in mid-2015, enabling HTTPS for your site
will be as easy as installing a small piece of certificate management
software on the server:
$ sudo apt-get install lets-encrypt
$ lets-encrypt example.com
That’s all there is to it! https://example.com is immediately live.
The Let’s Encrypt management software will:
Automatically prove to the Let’s Encrypt CA that you control the website
Obtain a browser-trusted certificate and set it up on your web server
Keep track of when your certificate is going to expire, and automatically renew it
Help you revoke the certificate if that ever becomes necessary.
No validation emails, no complicated configuration editing, no expired
certificates breaking your website. And of course, because Let’s
Encrypt provides certificates for free, no need to arrange payment.
I recently got a new code signing certificate. I'm using MSBuild's SignFile task to sign an application manifest. For some reason the task is returning:
MSB3481: The signing certificate could not be located.
Ensure that it is in the current user's personal store.
The certificate is definitely in my personal store, I can see it in certmgr.msc. And I believe that I'm logged in as the same user since I'm able to sign the manifest using a different certificate that is in the same personal store. Not sure why this new certificate cannot be found.
I'm even able to use signtool.exe with the new certificate's SHA1 to sign files just fine. But I would really prefer to use our existing MSBuild with the SignFile task. Any ideas what could be going wrong here?
I've also tried importing the certificate with and without the complete certification path.
I not sure that this could help, but I remember that if you are copying thumbprint from snap-in field, there is an "invisible" symbol in first position.
So this thumbprint with that non-printable can't be located in your store. Try to remove 3-5 symbols from beginning of certificate thumbprint (including quotes) and type them manually.
Also take in account that thumbprint should be all uppercase (despite that property displayed in lowercase).