I'm trying to set up a cfexchangeconnection to our office365 server to retrieve calendar settings but can't get the connection settings right.
If i do:
<cfexchangeconnection
action = "open"
connection = "exCon"
server = "outlook.office365.com"
username = "email#address"
password = "**********"
port="995">
I get 500: Could not log in to the Exchange server. Verify server name, username, and password.
I don't know if this means its an auth issue or whether I just got the server name wrong
If I take the port setting off I get the same error.
The server name is the one provided for setting up mail using imap or pop. The username is just the email and the password is obvious....
Switching the protocol to https I get the following error:
Cannot access Exchange server as a web application at outlook.office365.com.
Ensure that the Exchange web application is configured in IIS and Web Service Extension for the Exchange server is allowed. HTTP response code : 404
The below configuration worked for me. You have to install the certificate using keytool.exe. Make sure to add the serverversion, and select 2010. Also, make sure to specify https protocol. The default is 2007.
<cfexchangeconnection action="open"
username="#username#"
password="#password#"
mailboxname="#mailboxname#"
server="outlook.office365.com"
protocol="https"
serverversion="2010"
connection="testconn1"
formBasedAuthentication="true"
formBasedAuthenticationURL="https://outlook.office365.com/owa/auth/owaauth.dll">
Related
If I make a request to my Daphne/Django server in Postman or the Android app we're developing, Daphne serves the certificate, but it's rejected. If I first make a simple get request to https://letsencrypt.org/ and then make a request to my server, the certificate is accepted.
How can I make sure a client will trust my certificate, even if it's the first time this client is seeing a certificate issued by this CA?
Everything bellow can serve as a history of how I studied the problem.
Original title: SSL Certificate works in browser but can't be verified by Postman
I have an AWS EC2 instance running Ubuntu 18.04, with python 3, Django, a bunch of project dependencies, Daphne running with ASGI, with a certificate by Let's Encrypt. Daphne is using port 8000 for HTTP and por 4430 for HTTPS, iptables is configured to redirect requests from port 80 to 8000 and from port 443 to 4430. Django is configured to enforce secure connections with SECURE_SSL_REDIRECT=True in the settings.py file.
There's a "Site in Construction" temporary page being served, and it's properly accessible from every browser and every device I tested so far. If I explicitly type http, I get redirected to https and the certificate is accepted. Every browser I tested (Firefox, Brave, Chrome, Chrome for Android) says cert is good.
Curl outputs the HTML content returned from the server. I don't know if it accepts the certificate or ignores it.
The Problem
Postman, however, says "Error: unable to verify the first certificate". Only works when I disable "SSL certificate verification", which doesn't answer my question: why Postman is unable to verify my Let's Encrypt certificate?
I'm building an API that runs on the same server, using the same domain, and it's meant to be consumed by a mobile app. Currently, the Android app is throwing a "TypeError: Network request failed", which I suspect could be caused by the same thing Postman is complaining about.
When I spin the server locally and configure 1) the app to use http://localhost:8000 and 2) the server not to enforce SSL, it works in browsers, Postman and in the Android app.
I've being looking for answers in many places for days, so any clue will be very welcome.
EDIT
Interesting clue:
If I make a request to my Daphne/Django server, it servers the certificate, which is rejected. But if I first make a request to https://letsencrypt.org/ and then make a request to my server, it works!
This pattern holds true in both Postman and our Android app.
It also happens when I first make a request to https://alloy.city (instead of letsencrypt.org), which is served by a Node.js app, and uses a certificate also issued by the Let's Encrypt CA.
So maybe the question should be: how to configure my server to politely invite clients to add the CA that issued my certificate if they hadn't done it yet?.
Apparently, that's what my Node.js server does.
Yes, in settings, tap ssl verification off
File > Settings > General > SSL Certificate Verification > off
We have had issues with our server being used to send spam via cfmail to our remote SMTP server. I cannot see where it is occurring, but the emails are sent from a domain that is not one on our server.
Is there a way using ColdFusion administrator to specify that only emails showing as from someone#mydomain.com are sent to the SMTP host via the spool?
Thanks in advance,
Paul
It sounds to me like the <cfmail> side of things here is a red herring and you have got an open relay on your mail server. You seriously need to disable that immediately! If your SMTP server has to relay email for your CFML app then make sure it's not configured to relay everything, instead just for the IP address of the CF server, or for the credentials the CF server uses to connect to it.
If you don't know how to configure the relaying settings for your SMTP server, raise another question on serverfault.com asking how. Provide the exact details of your SMTP server, as well as the requirement to still allow relaying for the CF server.
I am trying to connect to an amazon server for sending emails by editing by web.config
<system.net>
<mailSettings>
<smtp deliveryMethod="Network">
<network enableSsl="true" port="587" host="email-smtp.us-east-1.amazonaws.com" password="actual password" userName="actual username"/>
</smtp>
</mailSettings>
</system.net>
These settings are being set as evidenced below:
All I am doing in code is
SmtpClient client = new SmtpClient();
client.SendCompleted += SendCompletedCallback;
string userState = _id.ToString();
client.SendAsync(msg, userState);
but the error I get back is always
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 184.73.222.29:587
Before I was using an internal mail server, but since this will be getting pushed to the amazon cloud, I will not have access to the local server. In the case of the local server, all i had to do was specify the ip address for host and it ran just fine.
There were three issues at hand:
1: The email address it was being sent from was not verified with Amazon, and neither was the recipient (verification of recipient only needed in sandbox mode)
2: The out port I was using, 587, is blocked by my company, which seems to be common practice
3: Using async can only be done when you specify the page uses async in the aspx "header"
I have a jax-ws web service developped using netbeans 7 and glassfish 3.1.2 .
I configured the web service to use Username authentication with symmetric keys security and default keystore.
When I test my web service in localhost everything work fine but when I delployed it in remote test server it didnt' work .
First I got exception complaining about Key used to decrypt EncryptedKey cannot be null so I uploaded the local keystore.jks and cacerts.jks to the remote server.
Now I'm gettinh those exceptions:
Server side:
WSITPVD0035: Error in Verifying Security in Inbound Message. com.sun.xml.wss.impl.PolicyViolationException: com.sun.xml.wss.impl.WssSoapFaultException: Invalid Security Header at
com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:151) at
com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.createMessage(SecurityRecipient.java:1003) at
com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:248) at
com.sun.xml.wss.provider.wsit.WSITServerAuthContext.verifyInboundMessage(WSITServerAuthContext.java:588) at
com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:361) at
com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:264) at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:173) at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144) at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119) at
com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961) at
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910) at
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873) at
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775) at
com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:386) at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:640) at
com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:263) at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:163) at
org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:120) at
org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:91) at
org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:200) at
org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:131) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:770) at
com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.doFilter(ServletAdapter.java:1059) at
com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.invokeFilterChain(ServletAdapter.java:999) at
com.sun.grizzly.http.servlet.ServletAdapter.doService(ServletAdapter.java:434) at
com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:384) at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179) at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at
com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354) at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at
com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at
com.sun.grizzly.ContextTask.run(ContextTask.java:71) at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at
java.lang.Thread.run(Thread.java:662) Caused by: com.sun.xml.wss.impl.WssSoapFaultException: Invalid Security Header at
com.sun.xml.ws.security.opt.impl.util.SOAPUtil.newSOAPFaultException(SOAPUtil.java:159) at
com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.processSecondaryPolicy(MessagePolicyVerifier.java:220) at
com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:144) ... 43 more
Client side:
Exception in thread "AWT-EventQueue-0" javax.xml.ws.soap.SOAPFaultException: Invalid Security Header
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:193)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:126)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:123)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
How can i fix this ?
Thanks .
The stack trace does not look familiar to me but maybe your problem is the certificate itself.
When you create a certificate you should set a 'server name'. This will be used by the client to check if the certificate's 'server name' match with the URL 'server name'. If the server names does not match the client should abort the connection because it can be an stolen certificate!!!. For more info, check this tutorial
Example with a java client: if you create a certificate for 'localhost' the client
verification will pass if and only if it access the web service using an URL
like 'https://localhost/stuff...'. So, if you tries to access the same application with the same client but using the IP like 'https://10.0.0.1/stuff...', a verification error should arise.
NOTE: The default configuration of a java web service client do this check, but If you want to bypass this client side verification please check this post
Try to check if this is the problem you are having. If it is the case you have several solutions:
Create a certificate for the server where you are deploying the
application
Disable client side verification
PS: I never did something special on the server-side to solve this kind of issues. Installing the correct certificate should be enough
In my case the problem was in CommandMap. Need to add "application/ciphervalue" handler in CommandMap, because WSIT does it only once while loading CVDataHandler class.
See com.sun.xml.ws.security.opt.impl.util.CVDataHandler static block for more details how to add.
What is the best way to debug a Django app that runs on top of TLS/SSL?
Background:
I have a Django web app that uses X.509 client side certificates for authentication. When running under Apache, my app can only be reached via HTTPS. Clients that connect to the app provide a client side certificate which Apache validates and then forwards to the app in an environment variable. The app parses the certificate and provides access controlled content.
So far, I have only been able to debug the app under regular HTTP, with "./manage.py runserver". I have simulated an HTTPS connection by using a custom view handler middleware that kicks in, in debug mode. The view handler adds information to the request, similar to the information that would be parsed out of an actual client side certificate when run under HTTPS.
It would make debugging much easier for me if I could debug with the actual client side certificates that clients provide when connecting via HTTPS.
We use nginx in front of Django, with client certificate checking. NGINX does the SSL termination, client cert validation, and checking against revocation list. The client cert fields are passed in header variables up to the django app.
So then our django app doesn't receive the cert, it just looks at the header variables. I think the same mechanism applies in Apache.
For clients accessing the development server (e.g. './manage.py runserver'), we simply have a special case in the client. Example of a python client:
if (proto == "https"):
conn = http.client.HTTPSConnection( "cert."+webhost+":"+port,
key_file = certfile, cert_file = certfile)
headers = {}
else:
# fake client for local connections. pass cert info in headers, as it would come
# out of nginx
conn = http.client.HTTPConnection( webhost+":"+port)
headers = { 'X_SSL_CLIENT_S_DN':'/C=US/ST=California/O=yyyy/CN=zzzz',
'X_SSL_CLIENT_I_DN':'/C=US/ST=California/O=xxxx/CN=wwww',
'X_SSL_CLIENT_SERIAL':hex(serialnum),
'USER_AGENT':"test client user agent",}
For unit tests, we do the same thing using the Django test client:
from django.test.client import Client
self.client = Client()
response = self.client.get(url, data,
**{
'HTTP_X_SSL_CLIENT_S_DN':'/C=US/ST=California/O=yyyy/CN=zzzz',
'HTTP_X_SSL_CLIENT_I_DN':'/C=US/ST=California/O=xxxx/CN=wwww',
'HTTP_X_SSL_CLIENT_SERIAL':hex(serialnum),
'HTTP_USER_AGENT':"test client user agent",
})
I've come up with a workaround that works fairly well for me. I still debug with HTTP, but I pass the client side certificate in via an HTTP header. So, when I debug the web app with HTTP, I have the clients copy the client side certificate into an HTTP header. Before entering the views, the web app copies the certificate from the header and into the regular location in which it would be passed by Apache when using HTTPS.
The client side certificates are PEM formatted so, to be able to pass them in HTTP headers, the only thing that needs to be done is to remove the newlines on the client and reinsert them on the server.
If using this approach, note that Apache's default limit for the size of a single HTTP header field is 8190 bytes, configured with the LimitRequestFieldSize directive. For certificates that are larger than that, the configuration must be changed or the certificate must be split up and passed in multiple headers.