For all docusign developers outthere. I'm using Docusign Connect to check the status of the envelop. I develop a listener that runs on tomcat. The reason why I used this because it's easier to code on my perspective and I want a push type data notification.
It works fine with HTTP, but I spend 2 days now and I still can't get it work for HTTPS.
My question is since the self signed certificate is not working. Do I need to purchase an SSL certificate for my web server?
or Docusign has a work around on this?
On demo sandboxes you can get away with testing without using HTTPS.
On production you will need a server that will actually support error free SSL connections. This means that you will need to wire up your tomcat to use some certificate that validates your website address. Whether it's a new one or just a wild card that you already have - that depends on the situation.
HTH
-mb
Related
I'm developing an app for a non-tech client that has outsourced the backend to another developer. We'll be launching the app under 7 different branded app, over a series of weeks. Each app is exactly the same, sans for the domain the API end points are on (IIS hosted).
As part of our security, we validate the SSL certificate when we connect to the API, and ensure the key returned by the API server matches our hardcoded version of it, as to prevent man-in-the-middle attacks to sniff our REST calls. We have this functioning now for the current server (1 of 7 to be rolled out).
We've asked the backend guys to provide the certificates for the remaining 6 sites, so we can deploy the apps with the expected keys. However, they claim that as they will be rolling out the sites individually over the coming weeks, each time they bring a new a new site online, they said they are "updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
Now whilst I'm no dummy, I'm also not a server admin, and only 99.9% sure that the SNI configuration to support another cert on the server, will not have any affect on the current certs already hosted for the existing domains. As a result, I wanted to explicitly confirm that the cert key we're validating as part of the SSL auth, is not going to change with each revision of the SNI config. The backend devs have essentially shut us down claiming we're paranoid, and going "beyond what is required" and to not expect "the same security a the major players offer" (as I mentioned that any decent commercial app validates its connection).
Is anyone able to confirm (or correct) my understanding of SNI as it relates to the certs, primarily that as they bring new sites online, that changes to the SNI have 0 impact on the existing certs for the current sites?
Edit: Whilst the use of multi-domain certs would regenerate the key, we can assume that they could generate/re-issue a multi-domain cert now in advance of the domains coming online. The question of if it's affected by the SNI config remains.
"updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
This is a weird argument. The point of SNI is that they can have multiple sites (domains) on the same IP address where each has its own certificate. If they add a new site only a new certificate for the new domain need to be created and all the other certificates will continue to work: a client using SNI will tell which site it wants to visit and the server then can pick the appropriate certificate. If they instead could not rely on SNI then they would have to use certificates which cover all sites on the same IP address.
So while it can be that they have some process which requires this kind of reissuing certificates it is not a requirement because of use of SNI, but only because they designed their process this way.
On my staging server I am connecting to self-signed https api backend. And by default requests can't be made, because browser treat backend as danger.
I have to open backend url in browser
https://my-api-backend.elasticbeanstalk.com
my-api-backend.elasticbeanstalk.com:8443 uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is not valid for the name my-api-backend.elasticbeanstalk.com. Error code: SEC_ERROR_UNKNOWN_ISSUER
After manually confirm that is secure it works. It is fine for me to do this, but not for managers etc. Another thing I was thinking about blocking backend access from outside and allow access only from frontend.
Is there any solution to this problem other than buying domain a sign it properly?
If it is a staging environment it should reflect a production environment so you should use a real domain signed correctly.
Certificates are free through AWS ACM or LetsEncrypt.
Why not use a sub domain like staging.domain.com, it would be free as well. Otherwise domains are cheap and it shouldn't be worth the hassle.
I have been working with web services connecting to URLs provided by different clients and so far it has all been done using one-way authentication. Now I'm asked to enable 2-way (mutual) authentication for one of the clients. I did a lot of research and reading but still confused about a lot of things.
I could test successfully on my local machine following instructions from various different articles. But the problem is now to deploy it in production.
Here's what I did for testing: I created a test Web service Host and assigned it a self-signed certificate and created a client to test this. After this I created a client certificate using makecert and verified that this is installed via MMC. I then modified my Host app to only allow clients with certificate and tested from client to see the connection refused due to not providing the client certificate. Then I modified the bindings in the client application to include the certificate name and I was able to connect to the Host successfully. So this completes local hosting.
Now the real problem. The tech team is going to create a certificate in "cert store" on the server. And I need to test again to make sure everything works as expected. We have a few different developers who all want to test on their machines on their local code. Can we all use the same certificate somehow? I don't think we would be allowed to import the certificate but what suggestions could I give them so all of us can use the same certificate?
I'm also confused about issues like difference between windows certificate and IIS certificate. What advantages would the IIS certificate provide?
Thanks for help!
Edit: Could one of the differences between installing on IIS be so that the hosted sites be accessed via SSL connection? This would mean we don't really need to install on IIS if it's just a client certificate. Is this correct?
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
Question: How can I securely include the SSL cert required for push notifications in the installer for my server product?
Background: Apple Push Notifications require a client SSL cert to be in place on the server that's making the calls to Apple.
My product has a traditional client/server architecture, i.e. a customer installs the server within their intranet and then obtains the iOS client from the App Store and connects the client to their instance of the server.
The point here is that the customer installs the server themselves, rather than a cloud architecture where I would manage the server myself.
My problem is that I don't know how to package the push notification certificate in the server installer in a secure way. I can't distribute the .p12 file without a password because that would expose my private key, and I can't use a password because the password would have to be included somewhere else in the installer which would defeat the purpose. Do I need to relay messages from all of my customers through a server that I manage, which has the SSL client cert? Do I need to install the SSL cert by hand into every one of my customers' sites?
Surely others must have run into this problem already? Or has everyone moved to the cloud?
Here is a major observation that happened to me over the weekend regarding Apple Push certificates. While there many references out there to setting up the Apple Push server side certificates, here is a MAJOR point I discovered that I cannot find referenced in any Apple documentation, or via google.
My situation: I have Push Certificates (sandbox) working great on Windows Server. Now it is time for production. Installation of production certs is successful like many times before. However, while the production push transmission completes error free, no pushes are generated to the device. Hmmm.
I just HAPPEN to notice that my Mac's time is roughly a minute off from the Windows Server (command-tabbing between MacOS and VM-Ware). Looking at Windows and Mac Settings, I see Windows internet time is set for "time.windows.com", and the mac for "time.apple.com". Just for kicks, I change the windows server time to "time.apple.com". Instantly, pushes are now being sent to the device. Nice. :-)
I dodged a major bullet here, this would have probably driven me insane trying to figure this one out. I do not claim to be an SSL cert guru... I (like most every one) just want to get this stuff to work because we have bigger fishes to fry.
I hope this is useful information.
I know only the solutions to install certificates for push notifications :
.p12, the password is in the code of the sending
.cer (.p12+private key) the password is requested at the importing of the certificate.
In the first case, you can deploy your solution, and download some code, for example xml with the password.