I am a new user for Microsoft Flows.
I have a requirement for Connecting the Microsoft Flow with HTTP Request.
When connecting the HTTP Request, I am using the Client Certificate with the .pfx certificate file.
I am using the below format :
{ "type": "ClientCertificate", "pfx": "aGVsbG8g...d29ybGQ=", "password": "myPassword" }
I am adding the pfx file in Base64 Encoding Format and Password in Plain Text format.
While running the Flow, I get the below error :
BadRequest. Unable to load the certificate private key. Please check that the password of the authentication certificate is correct, then try again.
Thanks, :)
I have had a similar experience, but the solution here is simple: The error message is right, either you have the wrong or incomplete base64 certificate string (copy-paste errors happen) or you have the wrong password to the certificate. There really is nothing more to it, the JSON form looks fine.
Related
Hi I'm tryinng to get access token using the below post URL https://accounts.adp.com/auth/oauth/v2/token?grant_type=client_credentials&scope=api and I'm setting basic authorization in header. While requesting I get 401 error.
{
"error": "invalid_request",
"error_description": "proper client ssl certificate was not presented"
}
It looks like you will need to resolve the issue of ADP issued client certificate first. https://developers.adp.com/articles/general/introduction-mutual-ssl (Mutual TLS/SSL Help from ADP Dev Site). You will need to contact your ADP support team if they have not issued you a client API (SSL) cert yet.
Im developing a Telegram bot using Qt c++, and i'm having problems trying to set a Webhook.
SSL Server
First of all, i've created a ssl server using QTcpServer and QSslSocket. Some explanations about this can be found in the QSslSocket doc. Also, i generated a self-signed certificate as Telegram doc explains here, using the command:
openssl req -newkey rsa:2048 -sha256 -nodes -keyout YOURPRIVATE.key -x509 -days 365 -out YOURPUBLIC.pem -subj "/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=YOURDOMAIN.EXAMPLE"
The result is a pair of files, a private.key file and a public.pem file. So, i used them in the QSslSockets to secure the connection.
The result of that is a ssl server capable of listen and accept connections. When i use a browser to connect to my ssl server, i obtain a warning about using a self-signed certificate (which i think is normal), but can connect to the server. From the server, i'm able of read the data that browser sent. So, i think the server side is good.
Request for setWebhook
In order to perform a request for setWebhook API method, i use QHttpMultipart class to create a MIME Multipart request. The API method needs the Url to be contacted and the public certificate. So, i use this code to generate the url parameter:
QList<QHttpPart> parameters;
QHttpPart urlPart;
urlPart.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("text/plain"));
urlPart.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"url\""));
urlPart.setBody(_url.toLatin1());
parameters.append(urlPart);
And this code to generate the certificate parameter:
QHttpPart filePath;
filePath.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"certificate\""));
QFile *file = new QFile(_filePath);
file->open(QIODevice::ReadOnly);
filePath.setBodyDevice(file);
file->setParent(this);
parameters.append(filePath);
I receive a correct response, with the message that "the webhook was set". But, when Telegram connects to my ssl server, the ssl handshake doesn't finish in a right way (neither encrypted() nor sslError() signals are emitted). I think that the problem is the way i upload the public certificate. As you can see, for the file QHttpPart, i doesn't set the content-type header because i don't know what value to use. I don't know if this can be the problem. I use "text/plain" for url, but don't know what to use for the certificate file.
So, i don't know what could be my problem. Even, i'm not sure if it could be the file upload or not. Using a self signed certificate is not a problem, since the documentation indicates this as a valid way. Any help would be appreciated.
Thanks in advance.
I finally found the problem, and it was the content-type. I removed the content-type of the first param, the urlPart. And also added the content-type to the filePath, using as value "application/x-x509-ca-cert". It works like a charm now.
I writing an application that using http request for authentication. Because of security matter, I am using WireShark to sniff the http packet to see if can steal the username and password.
When using WireShark, I got this encoded string:
TlRMTVNTUAADAAAAGAAYAHIAAADcANwAigAAAAQABABYAAAAEgASAFwAAAAEAAQAbgAAABAAEABmAQAAFYKI4gYDgCUAAAAP255D/F478qJlQoJwEti1LGgAcABzAGwAZQBlAGsAYgBvAG8AawBIAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGao0slMmaggkTP6jJJHJUwEBAAAAAAAABaWp/E9p0QGDaAQ319vuYgAAAAACAAQASABQAAEABABIAFAABAAEAGgAcAADAAQAaABwAAcACAAFpan8T2nRAQYABAACAAAACAAwADAAAAAAAAAAAQAAAAAgAAAkOEBAmC7E+a9Pa8Y4gF0J9zeqVTsT7BCXKEhznVGMpwoAEAAAAAAAAAAAAAAAAAAAAAAACQAkAEgAVABUAFAALwAxADkAMgAuADEANgA4AC4AMQAuADEAMQAzAAAAAAAAAAAAAAAAAFq8ggyPeAnfXnSiV12/Z1Y=
I do research online, and I guess this is Base64 encoded. Then, I tried to decode from this website:
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
I managed to see my username which is sleekbook, but the others still seems unknown to me. Is it because it's not Base64 encoding or it's further encrypted by some other algo as well?
In an ASP.Net web app, which runs on HTTPS and has RequireClientCertificate set in web.config, I need to receive the client certificate of the user and digital signature of the request on the server. The certificate is found in HttpContext.Request.ClientCertificate, but I can't find the signed data. The post params are automatically decoded and decrypted, but I need the signature too. Does anyone know where is it found or is it possible to get it?
One more question, when the browser asks for your certificate and hands it to the server, does it encrypt the whole HttpRequest with your private key or just a part of it (for example post params)?
Thanks for any help
One more question, when the browser asks for your certificate and
hands it to the server, does it encrypt the whole HttpRequest with
your private key or just a part of it (for example post params)?
Firstly, it doesn't make sense to "encrypt with a private key": you sign with a private key. While some algorithms (e.g. RSA) use very similar procedures to encrypt and sign, "encrypt" means "hiding" something: you're not hiding anything if anyone with the public key can decipher it.
Secondly, SSL/TLS uses symmetric keys (negotiated during the handshake) for encryption, not the keys in the certificates. The whole HTTP request will indeed be encrypted in this case.
The certificate is found in HttpContext.Request.ClientCertificate, but
I can't find the signed data. The post params are automatically
decoded and decrypted, but I need the signature too. Does anyone know
where is it found or is it possible to get it?
What's signed when using a client certificate is the handshake messages, not the HTTP request. Once the appropriate verification has been made by your SSL/TLS stack, it's unlikely to be of any use, either technically or administratively. (This is why it is generally not accessible.)
am sorry for this dumb question, but am using RawCap to detect packets sent and received to learn what is sent in HTTP, and the page is a simple application made using Tornado and MongoDB, when i capture packets, i dont find the password in any packet sent.
Why? i dont use any encrypted protocole like HTTPS, it's a simple HTTP and cant see the password.
here is the file:
The result
as you can see, Mongodb answers the value of the database, and brings the password as it is saved (PBKDF2), but cant see the one sent from the first time.
Most likely, you don't see the password because the page is using HTTP basic authentication which encodes the username and password using base64. Look for a string like:
Authorization: SomeRealmName QWxhZGRpbjpvcGVuIHNlc2FtZQ==
If you're using Basic authentication, then the password is base 64 encoded. ENCODED not encrypted. Look for something like this in your packets: Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=