I have a WSDL for a Web Service and a Public Key Certificate in the shape of a .cer file.
I need to get SoapUI to encrypt the service request with the public key of the certificate.
How do I do this?
In SoapUI, go to the Preferences dialog, under the File menu. There's a tab/section for SSL. There you can specify the path to the .cer file. I don't have it here in front of me, and I've only done .pfx, but it should work the same. With .pfx, you need to enter the password - not sure if you do that for .cer or not. You can also convert the .cer to .pfx if that works better. But anyway, with a .pfx specified here, I was able to use https connections to our server (Cisco ACE gateway actually) which required "client certificate authentication". It was easy to do in SoapUI, proving that the infrastructure was set up right. Our app, written in Delphi2005, took another 3 weeks... But at least we knew what we were trying to do, and had a way to verify the result.
In Preferences fill in the path to your certificate in the KeyStore field and the password underneath.
I use a p12 certificate and it seems to be working fine.
If you can use WCF, just add security to the binding, and the following behavior:
<behaviors>
<behavior>
<clientCredentials>
<clientCertificate findValue= "101010101010101010101010101010000000000"
storeLocation="LocalMachine" storeName="The logic storage"
X509FindType="The cert name"/>
</clientCertificate>
</clientCredentials>
</behavior>
</behaviors>
More info about how to enable security in WCF, see: MSDN
Related
I try to test REST api in Postman but every time I try to POST I get the following error
Error: self signed certificate in certificate chain.
I have tried with the SSL certificate verification on and off but both methods dont work. Postman is also updated to latest v7.3.6.
Tbh I dont know what to try anymore and would really appreciate any tip.
Go to Postman Settings > General > turn OFF SSL certificate verification
"make ssl certificate verification on and make it still work"
If you're under organization environment, you can:
Export your organization self-signed certificate as Base-64 encoded X.509 (.CER) format flat file. It could be done from Chrome.
Go back to Postman: Settings -> Certificates -> CA Certificates, switch on and select the file you just exported.
Adding CA certificates doesn't work for me. My certs are not self-signed but got the same error. Adding client certificates solved my problem. Quoted docs from Postman here: To send requests to an API that uses mutual TLS authentication, add your client certificate to Postman.
I used mkcert and here's how I managed to get rid of the error :
On the Site Information Icon, click where it's written Connection Not Secure
On the Connection Info dialog, click on More Information
On Page Info, click on View Certificate
On the Certificate tab, scroll down till where you'll see 2 links for the PEM files, and download the PEM (Chain) file
On Postman, go to Settings -> Certificates -> CA Certificates (make sure the toggle button is ON), and specify (click on Select File) the location of your PEM Chain file.
There you are !!!
I'm trying to connect with one of my client to call api methods from their server, the client want to have a bi-directional commnunication, they shared their security certificate which contains CACert.crt, another file with .crt, .key, .p7b, .pfx files. Now They want us to share our certificate. I've following questions:
How I install their certificate?
How I can generate my certificate? Do I need to purchase certificate for this or I need to generate something based on their certificate?
They mentioned about DataPower public certificate. After Googling, I found Datapower is from the IBM, can I create a free certificate from it?
I'm absolutely new to this, tried to google a lot, but couldn't make much sense.
It sounds like your client wants you to use a client certificate. They've provided you with a CA for you to use; just use that to fulfill the signing request for the certificate you generate.
I need to be able to hit a web service using SoapUI to inspect the request and response. I was previously provided with a certificate in the form of a .PFX file, along with the keystore password, which I could import into SoapUI and successfully hit the service.
The certificate I was provided recently expired, and my company has now deployed a new certificate via SCCM to my machine. I have the certificate installed in both Local Machine and Current User.
My question is:
Is there a way to use an installed certificate (meaning I can't export it first) to complete the SSL/TLS handshake when making a request via SoapUI?
Everything I've been able to find on the web has referenced exporting the certificate and setting the SSL settings in SoapUI (like I did before). Unfortunately, I do not have required authority to export the certificate to a .PFX file with a keystore password...
I assume there has to be a configuration setting of some sort in SoapUI that will let me hit the service with my installed certificate, but I can't find it for the life of me. Any help is greatly appreciated!
Even confirmation that it's impossible is appreciated; just not as much as I would appreciate a solution ;)
Thanks in advance!
I want to set up two way ssl(self-signed cert) to call a webservice endpoint from wildfly to weblogic. I've tested the weblogic setting, it works fine. Now, the problem is how should I configure the wildfly in order to build the connection with weblogic. I've tried the settings in standalone.xml as below:
<security-realm name="UndertowRealm">
<server-identities>
<ssl>
<keystore path="space2_identity.jks" relative-to="jboss.server.config.dir" keystore-password="password" alias="space2i" key-password="password"/>
</ssl>
</server-identities>
<authentication>
<truststore path="space2_trust.jks" relative-to="jboss.server.config.dir" keystore-password="password"/>
<local default-user="$local" skip-group-loading="true"/>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
</security-realm>
<https-listener name="https" verify-client="REQUIRED" security-realm="UndertowRealm" socket-binding="https"/>
The above setting is succeeded if I use a browser to run a two way ssl with wildfly. But for my main purpose (call WS between wildfly and weblogic), I keep receiving a bad_certification error, I suspect that wildfly cannot find my keystore and trustkeystore when wildfly is acting as a client role. It's because if I put the self-sign cert into jvm cacerts file, one way ssl can be built with weblogic. However, I've tried many methods to do the two way ssl, it keeps telling me bad_certification error. I've even insert the following lines into standalone.conf.bat:
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.debug=ssl"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.keyStore=D:/Keystore/space2_identity.jks"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStore=D:/Keystore/space2_trust.keystore"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.keyStorePassword=password"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStorePassword=password"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStoreType=jks"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.keyStoreType=jks"
Still, bad_certification received. I've tried many ways, what have I done wrong? Please kindly help. Thank you very much!
In your JAVA_OPTS the truststore is space2_trust.keystorewhile you have space2_trust.jks in your Undertow configuration.
I have a C# .net webservice that I need to restrict access to. I already require my consumers to use a username and password to call the service. But, is there a way to restrict access to the actual asmx page and the WSDL? I would need to restrict access to the webservice by username/password and IP address. If a user did not have the correct credentials, I would not want them to know what webmethods exist in the webservice.
Can this be done though IIS? I know that I can restrict IP addresses through IIS, but can I also use usernames/passwords?
Is there any other way to do this outside of IIS, maybe using C#.net?
Well, since it's ASMX you have the entire ASP.NET runtime stack at your disposal.
Step #1 - managing the resource through .config
Apply a <location> tag for the resources you want secured. Assuming it's a single ASMX file you can simply do the following in your web.config:
<location path="MyWebService.asmx">
<system.web>
<!-- resource specific options will go here -->
</system.web>
</location>
Step #2 - authenticating your users
You need to decide how you're actually going to authenticate users. There are several ways to do this and several authentication standards you could leverage. You need to pick the approach that's the right fit for you.
If you're on an intranet and are using Windows authentication I would highly suggest leveraging that because it's truly the simplest option to get setup. However, if your services are being accessed over the internet then Windows authenticatio is not really an option and you need to choose from a web standard. The simplest of those is Basic Authentication, but you should only use this over SSL since the username/password are not encrypted (only base64 encoded). The next step up from that is Digest authentication which doesn't require SSL because the username/password are sent using an MD5 hash. For the ultimate you can go with SSL v3 where you issue a specific client certificate to each user of your API.
Now, which option you select for security dictates what else needs to be done. If you choose Windows security, it's as easy as adding the following element to the <system.web> element we started with in Step #1:
<authentication mode="Windows" />
The remainder of the security protocols are going to require a little more work. ASP.NET doesn't provide intrinsic support for Basic, Digest or SSL v3. Technically you can leverage IIS to do this type of authentication for you, but it's always going to map to a Windows user. If that's an option for you, then simply leave the <authentication mode="Windows" /> element and configure IIS accordingly. If, however, that is not an option, either because you simply have no control over IIS/ActiveDirectory or you need to authenticate against a custom user database, then that means that you need to hook up a custom HttpModule to provide support for these security protocols.
Step #3 - securing the resource
The simplest approach to securing the resource is to basically say: "don't let anyone who hasn't successfully authenticated in some way into this resource". This is done using the following authorization configuration:
<authorization>
<deny users="?" />
</authorization>
If you wanted to only allow certain users you could change to do the following instead:
<authorization>
<deny users="*" />
<allow users="jdoe, msmith" />
</authorization>
Another approach is to define roles (groups) and simply lock the resource down to a special role which you put the users who you want to access the resource into.
<authorization>
<deny users="*" />
<allow roles="My Service Users" />
</authorization>
This maps well to Windows authentication because you can just setup a Windows group and let your MIS team manage which users are in that group using ActiveDirectory. However, the feature also works just fine for non-Windows authentication assuming the security implementation you've used exposes roles via its IPrincipal implementation.
I don't know how practical this is for you, but you could consider upgrading to WCF. WCF is fully backward compatible with ASMX web services, and lets you control whether or not the WSDL is exposed by defining a MEX (metadata exchange) endpoint. No MEX endpoint, no WSDL.
You can stop WSDL being shown by removing the Documentation protocol from the element in Machine.config
Update:
Web Services authentication - best practices?
If your users have usernames/passwords you can use HTTP basic authentication via HTTPS.
You can also implement it in a slightly differnt way. The first call to your web service should be the authentication method. Client authenticates and receives an authentication token. This token should be presented to all other methods exposed by your web service.
Two options: Create an entirely different site on a different port with locked down permissions. This has the advantage of providing some amount of "security through obscurity" (half joking...) Or you can add a new Application under your site(same port, different path), on a different app pool and assign permissions that way.
In either case, your web service isn't going to be able to talk with the various ASP.NET "things" like the application object (well it will, but it won't be the same one). Deployment is only slightly harder: deploy the same binaries, but only include the one web service file.
You can authenticate using an HttpModule.
SSL + BasicAuthentication should yield the best interop with other tool chains.
In the HttpModule, you have access to the request and can deny unauthenticated users access to just .asmx requests. And even then you might let them access the WSDL.
Add <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> to the <httpHandlers> section of the web.config file