Do I need to install certificate into my server if i am not using DocuSign Embedded Signing? - ssl

DocuSign documentation show that if using Embedded Signing or CONNECT, SSL need to implemented.
Security Certificates
If your integration uses Embedded Signing and/or DocuSign Connect Service, you may have to implement your SSL or X509 Certificate.
For Connect, please review our DocuSign Connect Service Guide, link provided below. You are required to provide a secure listener or an x509 Certificate.
If you use an x509 Certificate for Embedded Signing, please send your Account Manager the x509 Certificate’s Common Name, Issuer’s Name, Version, Serial Number, and Valid From and Valid To dates.
Does it mean that If i am not using the Embedded Signing or CONNECT then do I need to put the DocuSign root certificate into my server? I am just using the DocuSign Java Api that downloaded from Git.
If not which one to add? there are alot of certificates they have provided in this link DocuSign Trust

Docusign Connect sends HTTP POST messages to the endpoint you specify (i.e., to an endpoint on your server).
In the DocuSign demo environment (i.e., using your developer sandbox account), DocuSign Connect will send messages to either an HTTP or HTTPS endpoint.
However, in the DocuSign production environment (i.e., using a docusign.net account), DocuSign Connect requires that your endpoint be HTTPS. So when you're ready for your integration to 'go live' in the production environment, you'll need to ensure that the endpoint you've specified for Connect to send messages to is HTTPS (and if necessary, implement SSL to enable HTTPS for that endpoint).

Given what you said, and as long as you can make API calls (via HTTPS) without issue, then I would say you have no need to install any DocuSign certs.

Unfortunately that section of the document is out of date. Embedded signing does not require a customer to trust a DocuSign certificate.
I will work to get it updated.

Related

EPP For Domain Registration connection fails when using a certificate

I am using EPP (Extensible Provisioning Protocol) to perform domain registration operations.
Everything works fine but when I use a certificate, the login request fails.
Let us say I have certificate in C:\Folder\epp.crt and using the following code:
var tcpTransport = new TcpTransport(url, port, new X509Certificate("C:\Folder\epp.crt"), true);
var service = new Service(tcpTransport);
service.Connect();
This code executes just fine and service is connected. That means connection to URL is established using certificate. Now, I try to login with:
service.Execute(logingCmd);
But this gives me "Server requires Client certificate validation, no client certificate provided".
Why? Should there be any flag for certificate in login command?
Per RFC5734, EPP uses TLS, not TCP. This RFC also mandates use of client certificates.
Your question lacks details about the content of epp.crt (where is the associated key?) or the language you use. The TLS negotiation, including validation of client certificate happens before the EPP login, but the exact moment may be hidden by the library you use to connect.
So to answer your "Should there be any flag for certificate in Login Command?", no there should not as the certificate handling is part of the transport setup, not the EPP commands. Your problem is probably more around your use of TcpTransport.
You can use a network sniffer to see exactly what happens. Registries are probably not offering TLS1.3 for now so you should still be able to see the TLS exchanges, including your client providing a certificate.
Also the registry you connect to should be able to help you.

Self signed client certificate does not reach server application

I have the following setup:
A self signed certificate for development purposes
An OWIN hosted Web API, deployed on a local Azure Service Fabric Cluster as a ASF service. The Web API uses HTTPS facilitated with the dev certificate in question.
A simple .net client application that calls the Web API. In that application the ServicePointManager.ServerCertificateValidationCallback method is set so it always returns true (since the CA is not trusted)
Both the client application and the Web API are on the same local development machine. The certificate is installed in that same machine on the "machine store"
Now I am able to make calls to the web api using Fiddler by providing the required client certificate. However when I try to do the same via .net code (be it RestSharp or WebRequest) the client certificate is not present in the RequestContext object on the server side. This result in an Unauthorized response. I do not think the problem is with the client code, the certificate is loaded correctly and assigned to the http client or request. Fiddler shows encrypted tunneling to the server. However the client certificate does not seem to be present at the server side.
I am at a complete loss regarding what am I missing that could cause this behavior. Any help will be deeply appreciated.
Install the certificate into the 'Local Machine/Trusted People'.
The server needs to already trust the certificate before it asks. The CertificateRequest message that it sends lists the acceptable CAs that can sign the client certificate. If the client certificate's signer isn't in that message, it can't send it.
How you accomplish that in your environment is left as an exercise for the reader. In general now that SSL certificates are available free there is little reason to indulge in the time costs and administrative inconveniences of self-signed certificates. IMHO there wasn't even if you were paying for a CA signature.
I had a problem when a service called another service over HTTPS and it couldn't setup a secure connection. My problem was that since the service is running as NETWORK SERVICE, it couldn't find the certificate, because it was looking in the localmachine/my certificate store.
When I was running from my web browser it was working fine because then, my browser found the certificate in the currectuser/my certificate store.
Add the certificate to the machine/my store and see if it helps.

.Net web api, SSL + basic auth

I have multiple sets of sensor networks that are sending data to a .net web api. Somehow, I need to secure some of the endpoints of the API (so that I can be certain that the information sent to the API really is from the sensors). Basic auth and SSL seems to be one way to go. The problem is that I'm having trouble understanding the SSL part.
As of now I have created a client certificate that is stored on the sensors, information of the certificate can be retrieved in the API by the Request.GetClientCertificate() method. Is this overkill when I just want to secure my Api with basic auth? That is, is the communication secure by just sending data over https without providing a certificate?
I do not need to use the certificate for authentication (since this is done by basic auth).
Basic authentication is about sending the user name and password in the HTTP authorization header as plain text (base64 encoded but not encrypted). For this reason, you need to use HTTPS with basic authn so that folks in the middle do not get to see the user name and password that a client sends.
When it comes to HTTPS, there is a server certificate and a client certificate. Server sends the server certificate to the client so that client can determine it is the right server it is connecting to. Similarly, a client can send a client certificate to the server so that a server can determine if an authentic client is talking to it.
The client certificate part is optional in HTTPS. So, you can use basic authentication without using the client certificate. If you use client certificate, it is already a credential and you need not use basic authentication, unless you want to use a two-factor authentication. TFA is an overkill or not - it is for you to decide.

SSL - What should I do for it?

I need to enable SSL on my website.
Q1> What should I do to enable this service?
Q2> Should I change my code (i.e. PHP+JavaScript+MySQL )?
Thank you
Q1> you need to generate a certificate signing request and send it to a trusted certificate authority to be signed, usually for a fee. I use SSL.com regularly because they give me responsive customer support. After they sign the certificate, they will it send back to you or you can download it. Then you install the signed certificate on your server.
If you are running Windows, try http://www.ssltools.com/manager for a tool that generates the csr.
Q2> you can configure it in the server settings, but you can also programmatically implement it in your code. For instance, if you want to open sockets in your code, or if you want SSL on certain pages (although modern servers allow selective SSL implementation in the settings).

WebLogic 8.1 two-way SSL authentication on a web app full example?

Does anybody has a WebLogic 8.1 two-way SSL full example?
I am developing a small web application (1 HTML, 1 Servlet, 1 JSP) to send confidential data. The client could be a web browser. The server is WebLogic 8.1.
The information should travel encrypted. Besides, the web application needs to authenticate the client, using more than a username/password combination. I thought implementing using HTTPS and two-way SSL authentication. This way, the user should send me her certificate, I installed in the server, so the web application could know when it is sending information.
Now, I know how to use declarative authorization in a web application, but I am lost on how specify which users I recognize, and which are their certificates.
I just need a full example of this. A .war and/or the steps to do the basic case.
I don't think you'll find a full example easily and the question is a bit broad. But the link your provided is a very good starting point.
First configure Two-Way SSL and use CLIENT-CERT. Clients will need to buy a trusted client certificate or to generate a self-signed certificate that you'll need to add to the server trust store. This may be the hardest part if you're not familiar with PKI but I've added resources at the end of this answer that cover this part. Load the client certificate in each client browsers.
Second, configure an Identity Assertion provider to map the digital certificate of a Web browser to a user in a WebLogic Server security realm. If required, provide your own user name mapper or use the default one (which uses the attributes from the subject DN of the digital certificate or the distinguished name to map to the appropriate user in the WebLogic Server security realm).
Third, add users corresponding to the Subject's Distinguished Name (SubjectDN) attribute in the client's digital certificate in Weblogic Security Realm and assign them to groups.
Finally, use these groups in your declarative authorizations.
Sure, it won't be that easy if everything is new but that's basically what you need to do. Maybe start to implement it and open more specific questions if you need more guidance.
More resources:
Two-Way SSL in Weblogic for Developers
The Fifteen Minute Guide to Mutual Authentication
Certificate to User Mapping in WebLogic
How to Set Up X509 Certificate Authentication for Oracle WebLogic Server (transposable to WLS 8.1)