I am developing an API using a local server with a self signed SSL certificate.
Every time I make a request with PAW I get a dialog warning me that the certificate is self signed, and asking me if I would like to proceed.
This gets tiresome after the first few hundred requests.
Is there a way to tell PAW that I trust this certificate?
Here are the steps:
When the alert "Paw can't verify the identify of the remote server..." is shown
Click "Show Certificate"
Check the box "Always trust ... when connecting to ..."
Hit "Continue"
You probably will have to enter your system password to allow the Keychain to mark this certificate as trusted
Then on next calls, it won't prompt you again. See the short screencast here: http://cl.ly/3r102z170X3F
An alternative (but unsafe) way is to uncheck "Validate SSL Certificates" in the Preferences (Paw menu > Preferences), under the "HTTP" tab.
Hope this helps!
Related
I've a sub-application that I want to use windows authentication.
I want that login box pops up even in the domain when the person first reaches the page.
When I turn off Kernel-mode authentication, the login box pops up, but fails with error 401 Not Authorized after 3 login attempts.
If I turn this on, It doesn't even asks for the password,I believe this is due the computer is in the servers domain and the credentials are passed automatically.
Is there any possibility to show login form for all users, including domain users?
In the image below are my server configs.
Windows Authentication is normally handled by IIS. This is the way it works:
Client requests the page.
IIS returns a HTTP 401 response, with a header saying that it accepts Windows auth.
The client's browser automatically resends the request with the users credentials (as long as the site is trusted).
IIS verifies the user and passes the credentials to the application.
This is all designed to be seamless.
If you want the user to be prompted for credentials all the time, then either:
Make sure your site is not trusted (not in the Internet Options Trusted Sites or Intranet Sites). But you may not be able to do that.
Don't use Windows authentication. Uses Forms authentication and make a login page where the users can enter their credentials. But that means that you will have to verify the credentials against Windows or Active Directory yourself in your code.
If you use #2, then also make sure to use SSL on your site since passwords will be sent in plain text.
You can use Basic authentication. It will prompt the user for credentials and once entered, it will give you a seamless experience.
However, the disadvantage with basic auth is that it sends the password in plain text to the server. You can use SSL certificate to encrypt this information.
I'm using ASP.NET, and IIS web server. I want to use HTTPS protocol on my web site. In my IIS web server, I binded my web site on port 443 using following procedure:
Open IIS
Chose site I want to configure (in my case "My Test site")
Click Bindings on right side of window
In new window I deleted http, and added https (IIS asks you a
certificate file, which I previously created)
Click OK
Click browse on right side of IIS window
Am I using HTTPS now, and is all my data is encrypted?
It should be. However to ensure that the data is encrypted, you can do this further check.
Open the site in the browser and if you are using firefox, you should see a green colored label near the address bar, on internet explorer, you will see a lock sign - in short, there will be some sort of security information. Open it and check it. It will show the status of certificate and will also show you if the site is protected or not.
This is the final test at client side. If you have proper certificate installed which could be validated, it would say that the site is protected, otherwise it would say that the data is encrypted but the certificate is not valid - kind of security exception.
I have a client who wants to secure the connection to his application with a client certificate. He doesn't want to map the certificate to a login.
He doesn't want to buy a certificate from trusted CA and wants me to provide him my own self-signed certificate.
I followed the steps from this article :
http://asoftwaredeveloper.wordpress.com/2011/12/30/x-509-certificate/
(every time I search on Google I end on this)
I managed to generate the two certificates and to set them both up in the client and server.
However, I still get the same 403.7 error.
Does anybody have a real step by step guide with ALL the steps?
Am I the only one who wants to do such a simple thing?
Why isn't it clearly described in the documentation?
Here is a step by step:
Generate your CA
Generate your client certs and add sign them with the CA
Open MMC (Windows 7 just type MMC in the dialog)
Click file>add/remove snap-in...
Click certificates then add
When prompted select computer account
When prompted again select local computer
Double click on certificates
Click on Trusted Root Certification Authorities
Click on certificates
Click on more actions > import
Find and select your Root CA Certificate
13 Open Internet Information Services Manager
Click on your server
Click on Server Certificates
Import your CA certificate
Click on your site
Click on bindings
Add a new one for https
Make sure to select your CA certificate
Click ok.
Return to your site menu
Click on SSL Settings
Check require SSL
Click on require in the radio buttons
Return to site's menu
Click on authentication
Enable anonymous authentication (it will still ask for a certificate)
Restart IIS (all of it, not just the site)
Install the client certificate into the browser
Go to the site with https:// and not http://
Browser should prompt depending on settings
Every client must trust the CA so you will have to convince every user to install your CA cert to their computer.
There are a lot of articles talking about this error and how to resolve it. I'm assuming it is a semi catch all error report for different types of connectivity issues. Here is my scenario, I hope someone can help me to figure out what is wrong. I'm somewhat new to this.
I have a fax server using XMediusFax. I use their API to communicate with the server to send faxes and check the status of the faxes. My DLLs are all registered correctly on my machine, and I have the certificate setup under the Trusted Root Certification Authorities section.
If I call my code in a standard VBS script it works 100% fine. If I move the code into my ASP website it gives me the error: Could not establish trust relationship for the SSL/TLS secure channel. I opened IIS 7, went to my site, went to Authentication, selected the Anonymous Authentication option, and changed it from the default value of IUSR to my domain login. After doing that It works great from my website.
Modifying the Anonymous Authentication is not a solution I would want to roll out to customers. Does anyone have a less brute force approach that I could try? I did try setting my app pools identity to my domain account and that didn't fix the issue.
I believe that your issue may be caused by the fact the web service call between your application and XMediusFAX is executed under the context of the IUSR account. The XMediusFAX certificate that you have added to your trusted certificates applies to your user account, not to the IUSR account. When you replace IUSR with your account, it works, since it gets your list of trusted certificates.
There may be a few solutions available to you, depending on your needs. For example:
You could setup a local account (on the IIS server), select it for the anonymous user identity, login with that account and add the
XMediusFAX certificate to the trusted certificates of this account
You could have your XMediusFAX certificate signed by a trusted authority
You could implement a callback in your application to decide what to do with the certificate proposed by the XMediusFAX server
This last option may be a good one for you. I don't know the details of your application, but I would suggest that you take a look at RemoteCertificateValidationCallback to define a method to override the default certificate validation. In fact, if you don't really care about validating the server's identity, you can simply have your callback return true without doing any validation.
Hope this helps.
When I try to get data in a mobile flex app from a secure site, I get following alert:
A secure connection with this site cannot be verified. Would you still
like to proceed? The certificate you are viewing does not match the
name of the site you are trying to view.
For each call, I get the popup. If I keep on clicking Yes, the app works fine (but I would like to avoid that ;-)).
Any ideas? Apparently, the url from where the request comes, is not the same as defined in the certificate... But what is the url if called from a mobile app (standalone)? It's neither an error, because you can click on yes. So it's more that the client gives a warning. The annoying thing is that you can't accept it permanently...
This is the same whenever a cert is not correct and chrome or firefox alerts you and asks if you want to proceed. You cant accept a faulty cert on the behalf of your users. The easiest way to fix this is to tell the site owner to get a proper cert.
Check with your system administrators of website whether certificate installed is issued for your domain. It appears that certificate is issued for a domain https:///xxxx where as it is installed on https://yyyy
Bypassing is OK for testing , it seems finally you will have to get this corrected
In my experience this only comes up with self-signed certs, expired certs, and when you are calling the cert by a URL that is not identified in the cert.
With most certs they are associated with a single host/domain combination, i.e. https://www.domain.com
That means that they cannot be used with any other domain host combination. Not even http://domain.com or https://sub.domain.com.
There are certs that will support different hosts on the same domain (www.domain.com, sub.domain.com, etc). They are called wildcard cert. They are very expensive compared to normal single domain certs.
My guess is that in the browser you are calling www.domain.com but in your AIR app you are calling domain.com or calling some other host. That or you have permanently accepted the improper cert in the browser.
I have never have a problem with anything improperly identifying a valid cert. Not a browser, Flex app, AIR application. Ever.
If you view the cert in the browser you should be able to see what domain/host it is registered to. Make sure you are using exactly that. Any variation will cause the error.
As a temporarily solution I added some exceptions to the URL Rewrite Module, so that communication by Mobile App can be done with HTTP. But it's no longer secure, so I would rather use HTTPS.
I have also faces this issue and simple solution is fixed the certificate issue. If not possible then forget about using the HTTPS use HTTP only. So you never get any complain about any certificate issue.