Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/26/20 09:08, Mark Thomas wrote: > On 26/02/2020 11:19, Mark Thomas wrote: >> On 26/02/2020 09:00, Mark Thomas wrote: >>> On 25/02/2020 21:47, Ellen Meiselman wrote: So it turned out that the logs were mostly set at FINE already, so >>> Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request > >>> to > non-secire AJP. I don’t think this was a problem on the other servers before but the >>> security has probably been tightened, and it just doesn’t >>> produce an error - it just won’t allow it. I have had IIS set to require SSL, but I turned it off to test and it >>> actually worked all the way through to the simple.html file. so >>> it’s some sort of policy about downgrading - which seems quite >>> rational in retrospect >>> >>> Thanks for the new information. >>> >>> That rules out an issue with the secret settings. >>> >>> I wonder if IIS (or more likely the ISAPI redirector) is adding >>> some unexpected request attributes that is triggering the new >>> protection for CVE-2020-1938. If that is the case, adding the >>> following to your AJP connector in server.xml should get things >>> working for SSL as well: >>> >>> allowedRequestAttributesPattern=".*" >>> >>> Meanwhile, I'll configure my local test environment for IIS >>> with TLS and see what happens. >> >> Confirmed. That is the issue and >> allowedRequestAttributesPattern=".*" works around it. >> >> I need to debug further to find out exactly what the attributes >> are. I expect we'll add them to the ones Tomcat accepts by >> default. > > Added. > > Fixed in: - master for 10.0.0-M2 onwards - 9.0.x for 9.0.32 > onwards - 8.5.x for 8.5.52 onwards - 7.0.x for 7.0.101 onwards > > For reference, the IIS specific attributes will be listed in the > docs. CI version available from: > https://ci.apache.org/projects/tomcat/tomcat9/docs/config/ajp.html#Sta ndard_Implementations Well, > @#$*%&. Sorry, IIS folks. I hope we didn't ruin too many nights and weekends for you. :( - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5WpxcACgkQHPApP6U8 pFiCQBAAqM4R2meJGpAIgO4wAyqW4999+ZCF7AXtyXH0wDa7//RAhNzaNnNvNLNB 5XPQdwhxB5/Ckq7MYL1WBIKnwUZ052EBMnZTIgyOI8SP4NbUdPsovKAD8UAdoFOQ 48drsY27D2ltj9Xqja2hsvAEDLt1A2K3NF3CwhAMZCDz37SyHSpuOOEmSFJ0S1Q8 OtKMtSUsxGVPYmQR1CZwg18Q8XM6S8Rg5GRRpJHEowJ74+3C6CcYBk+i3xFMYMfN WkHEjYZQetyVnvgJqNI0NDsErWehfQ38sZGPsFewtYWXemwAAfnDeVUkr5XXYHSz UmMMlclZnG2CQLpHSklVKKuRJeRDO7CFijNQVkwZwpBtQa1tZFvpUQnsWD6SrXq2 YzGUTQBWHpEL9ZjSuws+uI3H4QmpFp1WhSuOMZoPHpE6m804Q1onWqFe+RPPW8E0 g5ykhzFPE7uo3gBpMUIkuiGVlnMFIQas98K7WApcHXOKryAwSjIBXclNcE5OSVuf synopXnR6w61Fymoq+sr5sTJ64gbVQlsfFDsWvRJhak14Zzt6ZJu3a2T14Yt9Fz3 5NHJZDX9j5gQbfE9ATuoj4L40n7LkE0SrLYaagzkT3B5UaV0IMRdQIyki7bJdV26 zfgAyER3hnC8qEN3THeBPtRVqPpXvXel+AyqRsKgq9RWhMqoPyw= =5nQA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
On 26/02/2020 11:19, Mark Thomas wrote: > On 26/02/2020 09:00, Mark Thomas wrote: >> On 25/02/2020 21:47, Ellen Meiselman wrote: >>> So it turned out that the logs were mostly set at FINE already, so >> Johann’s suggestion was already done. >>> >>> But I think I now know where the problem lies. Secure IIS request > >> to > non-secire AJP. >>> >>> I don’t think this was a problem on the other servers before but the >> security has probably been tightened, and it just doesn’t produce an >> error - it just won’t allow it. >>> >>> I have had IIS set to require SSL, but I turned it off to test and it >> actually worked all the way through to the simple.html file. so it’s >> some sort of policy about downgrading - which seems quite rational in >> retrospect >> >> Thanks for the new information. >> >> That rules out an issue with the secret settings. >> >> I wonder if IIS (or more likely the ISAPI redirector) is adding some >> unexpected request attributes that is triggering the new protection for >> CVE-2020-1938. If that is the case, adding the following to your AJP >> connector in server.xml should get things working for SSL as well: >> >> allowedRequestAttributesPattern=".*" >> >> Meanwhile, I'll configure my local test environment for IIS with TLS and >> see what happens. > > Confirmed. That is the issue and allowedRequestAttributesPattern=".*" > works around it. > > I need to debug further to find out exactly what the attributes are. I > expect we'll add them to the ones Tomcat accepts by default. Added. Fixed in: - master for 10.0.0-M2 onwards - 9.0.x for 9.0.32 onwards - 8.5.x for 8.5.52 onwards - 7.0.x for 7.0.101 onwards For reference, the IIS specific attributes will be listed in the docs. CI version available from: https://ci.apache.org/projects/tomcat/tomcat9/docs/config/ajp.html#Standard_Implementations Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Thank you for that - I wasn't sure what patterns were allowed with that attribute, so I couldn't test it. I'll check the isapi_redirect.log to see if it records the exact requests. On Wed, Feb 26, 2020 at 4:01 AM Mark Thomas wrote: > On 25/02/2020 21:47, Ellen Meiselman wrote: > > So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. > > > > But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. > > > > I don’t think this was a problem on the other servers before but the > security has probably been tightened, and it just doesn’t produce an > error - it just won’t allow it. > > > > I have had IIS set to require SSL, but I turned it off to test and it > actually worked all the way through to the simple.html file. so it’s > some sort of policy about downgrading - which seems quite rational in > retrospect > > Thanks for the new information. > > That rules out an issue with the secret settings. > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > unexpected request attributes that is triggering the new protection for > CVE-2020-1938. If that is the case, adding the following to your AJP > connector in server.xml should get things working for SSL as well: > > allowedRequestAttributesPattern=".*" > > Meanwhile, I'll configure my local test environment for IIS with TLS and > see what happens. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
On 26/02/2020 09:00, Mark Thomas wrote: > On 25/02/2020 21:47, Ellen Meiselman wrote: >> So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. >> >> But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. >> >> I don’t think this was a problem on the other servers before but the > security has probably been tightened, and it just doesn’t produce an > error - it just won’t allow it. >> >> I have had IIS set to require SSL, but I turned it off to test and it > actually worked all the way through to the simple.html file. so it’s > some sort of policy about downgrading - which seems quite rational in > retrospect > > Thanks for the new information. > > That rules out an issue with the secret settings. > > I wonder if IIS (or more likely the ISAPI redirector) is adding some > unexpected request attributes that is triggering the new protection for > CVE-2020-1938. If that is the case, adding the following to your AJP > connector in server.xml should get things working for SSL as well: > > allowedRequestAttributesPattern=".*" > > Meanwhile, I'll configure my local test environment for IIS with TLS and > see what happens. Confirmed. That is the issue and allowedRequestAttributesPattern=".*" works around it. I need to debug further to find out exactly what the attributes are. I expect we'll add them to the ones Tomcat accepts by default. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hi. I think that we are getting complicated and confusing here. A picture is worth a thousand words, so a little ASCII graphic art may help clarifying things. browser <-(1)-> IIS + proxy <-(2)-> tomcat <-> application - connection (1) can be HTTP or HTTPS (admin choice) - connection (2) can be HTTP, HTTPS, or AJP (admin choice) To simplify, let's say that connection (1) is always HTTPS. In principle, even if connection (1) is HTTPS, IIS should be able to "proxy" the requests to Tomcat over HTTP,HTTPS, or AJP, depending on the configuration of a) IIS itself b) the proxy add-on module inside IIS A) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(AJP)-> tomcat <-> application then : - the proxy module to use in IIS is isapi_redirector - the target Connector/port in tomcat is an AJP connector - AJP is a protocol similar to HTTP/HTTPS, but it is different from them both, and it does not support encryption B) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(HTTP)-> tomcat <-> application then : - the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy module within IIS. I do not know which one or how to configure it, because I am not an IIS specialist. But it is probably a built-in module in the standard IIS. - the target Connector/port in tomcat is an HTTP Connector - HTTP is not encrypted, but it does not matter very much here, because the connection is only within the same host. C) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(HTTPS)-> tomcat <-> application then : - the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy module within IIS. same comment as for (B) - the target Connector/port in tomcat is an HTTPS Connector - HTTPS is encrypted, but this is taken care of by the proxy module on the IIS side, and the HTTPS Connector on the Tomcat side. All 3 solutions above are completely equivalent in terms of forwarding (some) requests to tomcat. But maybe something to insist on : only solution (A) above requires isapi_redirector. workers.properties is something which is /only/ used by isapi_redirector, so if you choose solutions (B) or (C), you do not need that file at all. And I do not know if it possible (but presumably it is) to configure IIS to do (B). But that is something for which in principle we cannot help you on this list, because we are not IIS specialists here. Does this make things clearer ? On 26.02.2020 00:17, Ellen Meiselman wrote: Hi Chris, Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. Incoming connections require SSL or will be upgraded to SSL. So if you type in http, it will change to https. Right now because I do not have SSL set as required, I can type in http and it stays http. At that point, it starts working - I no longer get the 403 from Tomcat. My recommendation would be to take this opportunity to switch to HTTPS and dump AJP. OK, I am willing to try - so to do that, would this be the procedure? 1. Set up certificates in Tomcat (big black box for me, but I'll try to figure it out) 2. Change the worker.worker1.type to HTTPS 3. Change the worker.worker1.port to 8443 Anything else? Ellen On Tue, Feb 25, 2020 at 5:47 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, Oops pressed SEND before I was done... On 2/25/20 16:47, Ellen Meiselman wrote: So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request to > non-secire AJP. I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. I have had IIS set to require SSL Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect. For example, this HTTP address does work. http://my.servers.domain.com/exposedApplication/simple.html I never tried it because I knew I had set SSL to required. Sometimes you make assumptions that block progress. This HTTPS address does not work - I get the 403 from tomcat. https://my.servers.domain.com/exposedApplication/simple.html So - if this makes sense to any of you, please tell me roughly what I need to do to make the AJP requests as secure as the port 80 requests. Um... I know keystores and .pem files are involved, but please give me the big picture - what port does AJP need to run on, and where do I go to find out how to tell it to use a “real" cert. Traditionally, AJP is run over port 8009 but you can always
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
On 25/02/2020 21:47, Ellen Meiselman wrote: > So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. > > But I think I now know where the problem lies. Secure IIS request > to > non-secire AJP. > > I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. > > I have had IIS set to require SSL, but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect Thanks for the new information. That rules out an issue with the secret settings. I wonder if IIS (or more likely the ISAPI redirector) is adding some unexpected request attributes that is triggering the new protection for CVE-2020-1938. If that is the case, adding the following to your AJP connector in server.xml should get things working for SSL as well: allowedRequestAttributesPattern=".*" Meanwhile, I'll configure my local test environment for IIS with TLS and see what happens. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hi Chris, > Does this mean that incoming connections require SSL or aso outgoing > (e.g. proxy) connections? I'm super ignorant of IIS configuration. > Incoming connections require SSL or will be upgraded to SSL. So if you > type in http, it will change to https. Right now because I do not have SSL set as required, I can type in http and it stays http. At that point, it starts working - I no longer get the 403 from Tomcat. My recommendation would be to take this opportunity to switch to HTTPS > and dump AJP. OK, I am willing to try - so to do that, would this be the procedure? 1. Set up certificates in Tomcat (big black box for me, but I'll try to figure it out) 2. Change the worker.worker1.type to HTTPS 3. Change the worker.worker1.port to 8443 Anything else? Ellen On Tue, Feb 25, 2020 at 5:47 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Ellen, > > Oops pressed SEND before I was done... > > On 2/25/20 16:47, Ellen Meiselman wrote: > > So it turned out that the logs were mostly set at FINE already, so > > Johann’s suggestion was already done. > > > > But I think I now know where the problem lies. Secure IIS request > > > to > non-secire AJP. > > > > I don’t think this was a problem on the other servers before but > > the security has probably been tightened, and it just doesn’t > > produce an error - it just won’t allow it. > > > > I have had IIS set to require SSL > > Does this mean that incoming connections require SSL or aso outgoing > (e.g. proxy) connections? I'm super ignorant of IIS configuration. > > > but I turned it off to test and it actually worked all the way > > through to the simple.html file. so it’s some sort of policy about > > downgrading - which seems quite rational in retrospect. For > > example, this HTTP address does work. > > > > http://my.servers.domain.com/exposedApplication/simple.html > > > > I never tried it because I knew I had set SSL to required. > > Sometimes you make assumptions that block progress. > > > > This HTTPS address does not work - I get the 403 from tomcat. > > https://my.servers.domain.com/exposedApplication/simple.html > > > > So - if this makes sense to any of you, please tell me roughly > > what I need to do to make the AJP requests as secure as the port 80 > > requests. > > Um... > > > I know keystores and .pem files are involved, but please give me > > the big picture - what port does AJP need to run on, and where do > > I go to find out how to tell it to use a “real" cert. > > Traditionally, AJP is run over port 8009 but you can always choose any > port you wish as long as both sides of the connection (IIs, Tomcat) > agree on which port to use. > > AJP is a non-secure protocol, full stop. You can tunnel it through > other things but, as some have mentioned, since you are using > localhost it's not super important to use encryption. > > If you DO need encryption, you have two choices: > > 1. tunnel AJP over e.g. TLS using a tool like stunnel, which is > actually available for Windows. It's a little more "at home" in *NIX > environments, but I've header it works just as well on Windows. If you > do this, you WILL need to deal with keys and certs. > > 2. Drop AJP and use HTTPS. I don't believe there aren't any features > you can't get working through HTTP that AJP provides. I think this > also means you no longer need a special IIS redirector plug-in > anymore, so it's 100% vanilla IIS at that point. If you do this, you > WILL need to deal with keys and certs. > > But are you sure you need encryption? > > If you are using localhost, it's worthless IMHO. If you are traversing > a network -- even a "trusted" one -- it's a hard requirement also IMHO. > > My recommendation would be to take this opportunity to switch to HTTPS > and dump AJP. > > > Also I’ll have to figure out how to shut off port 8080 or require > > SSL on tomcat once I get everything going. Actually I’d like to > > limit Tomcat to responding to requests from the server itself. > > Nothing should be talking to Tomcat but the isapi connector. > > Bind to address="127.0.0.1" and only on ports that IIS is using for > proxying. If that means AJP over 8009, then use that. If that means > HTTPS over port 8443, then use that. Just comment-out the connector > you DON'T need. > > You'll never really know what protocol the client is using to talk to > the (reverse) proxy, so you have to make some assumptions. If you have > configured IIS to only proxy requests over a secure channel from the > client (which I highly recommend!) then you can assume that all > connections, regardless of protocol or port are indeed secure where it > counts: between the client and the reverse proxy. > > If you only want "secure" connections from the client, then you will > want to set both secure="true, scheme="https", and proxyPort="443" on > your . This makes Tomcat generate https:// URLs with the > right port number, etc. for redirects,
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, Oops pressed SEND before I was done... On 2/25/20 16:47, Ellen Meiselman wrote: > So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. > > But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. > > I don’t think this was a problem on the other servers before but > the security has probably been tightened, and it just doesn’t > produce an error - it just won’t allow it. > > I have had IIS set to require SSL Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. > but I turned it off to test and it actually worked all the way > through to the simple.html file. so it’s some sort of policy about > downgrading - which seems quite rational in retrospect. For > example, this HTTP address does work. > > http://my.servers.domain.com/exposedApplication/simple.html > > I never tried it because I knew I had set SSL to required. > Sometimes you make assumptions that block progress. > > This HTTPS address does not work - I get the 403 from tomcat. > https://my.servers.domain.com/exposedApplication/simple.html > > So - if this makes sense to any of you, please tell me roughly > what I need to do to make the AJP requests as secure as the port 80 > requests. Um... > I know keystores and .pem files are involved, but please give me > the big picture - what port does AJP need to run on, and where do > I go to find out how to tell it to use a “real" cert. Traditionally, AJP is run over port 8009 but you can always choose any port you wish as long as both sides of the connection (IIs, Tomcat) agree on which port to use. AJP is a non-secure protocol, full stop. You can tunnel it through other things but, as some have mentioned, since you are using localhost it's not super important to use encryption. If you DO need encryption, you have two choices: 1. tunnel AJP over e.g. TLS using a tool like stunnel, which is actually available for Windows. It's a little more "at home" in *NIX environments, but I've header it works just as well on Windows. If you do this, you WILL need to deal with keys and certs. 2. Drop AJP and use HTTPS. I don't believe there aren't any features you can't get working through HTTP that AJP provides. I think this also means you no longer need a special IIS redirector plug-in anymore, so it's 100% vanilla IIS at that point. If you do this, you WILL need to deal with keys and certs. But are you sure you need encryption? If you are using localhost, it's worthless IMHO. If you are traversing a network -- even a "trusted" one -- it's a hard requirement also IMHO. My recommendation would be to take this opportunity to switch to HTTPS and dump AJP. > Also I’ll have to figure out how to shut off port 8080 or require > SSL on tomcat once I get everything going. Actually I’d like to > limit Tomcat to responding to requests from the server itself. > Nothing should be talking to Tomcat but the isapi connector. Bind to address="127.0.0.1" and only on ports that IIS is using for proxying. If that means AJP over 8009, then use that. If that means HTTPS over port 8443, then use that. Just comment-out the connector you DON'T need. You'll never really know what protocol the client is using to talk to the (reverse) proxy, so you have to make some assumptions. If you have configured IIS to only proxy requests over a secure channel from the client (which I highly recommend!) then you can assume that all connections, regardless of protocol or port are indeed secure where it counts: between the client and the reverse proxy. If you only want "secure" connections from the client, then you will want to set both secure="true, scheme="https", and proxyPort="443" on your . This makes Tomcat generate https:// URLs with the right port number, etc. for redirects, and also won't cause a redirect storm if the application specifies that it wants to use only "secure" connections (which I also highly recommend). - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5VpAUACgkQHPApP6U8 pFhTGhAAuvtGHsUj3/67e27AV7LLwMxFBQ/FtsdiXEgx0AjX6iwmgmtqQTvtUchv aTKoVTPMI+y/2+JOo+BXa7M63Tf7z7OuTbsyTN2b9ooAsWLKQMt0jVycbT65oAEx kRLgpoWAxgy6dwEu8BF/qW13HA4VCmAuU0PSMzsbFWVEyLuG8K8FA9oT2S0p5tuZ pbgPFjcda0uGs6KTb2jx+IWHBe22wdBxM4rcOFmhynfTmMpc4klXLpypoNDys/AK vy1a3xvGGy4d9BxOUs9/h/LZIMfZV+NoE5cEu9VgvURQonnbFjbGspBqljAjiuTn NplgdovCcfXKSryFDPtxG7q/vmUnrhgxyzW6fqhHjZvCTJXVAXUONTK375EkUNve 5Eada14fISxRR4r2Xyh2f6x/sJBnDkQaDVxD1FVYEAXCDarkq8kvfbWZiSkwEMIv 0NPWppUsMDFI0LG2pwpEwSWtg4bSnPxkF3/AtIKUrreqUMTQQzNfChLkXRm+pzv0 s2+qrCAeQxQ/K4PUknGErOQjcOAI7t5kcmx3u+r9ir9F3DvPISUVaZaCHoVDNzgH Q3O4DCPZ25N4AgV7hE+vm5rxcEUQkWdCu2uylNJBULqnkgx8vSHHxcif7qhzbf1K rPoujP3Dsm3UwHcJPqUr4d3pyauxl4YYT6xoz2eP0tQckCMmFvw= =WS1y -END PGP SIGNATURE-
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, On 2/25/20 16:47, Ellen Meiselman wrote: > So it turned out that the logs were mostly set at FINE already, so > Johann’s suggestion was already done. > > But I think I now know where the problem lies. Secure IIS request > > to > non-secire AJP. > > I don’t think this was a problem on the other servers before but > the security has probably been tightened, and it just doesn’t > produce an error - it just won’t allow it. > > I have had IIS set to require SSL Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. > but I turned it off to test and it actually worked all the way > through to the simple.html file. so it’s some sort of policy about > downgrading - which seems quite rational in retrospect. For > example, this HTTP address does work. > > http://my.servers.domain.com/exposedApplication/simple.html > > I never tried it because I knew I had set SSL to required. > Sometimes you make assumptions that block progress. > > This HTTPS address does not work - I get the 403 from tomcat. > https://my.servers.domain.com/exposedApplication/simple.html > > So - if this makes sense to any of you, please tell me roughly > what I need to do to make the AJP requests as secure as the port > 80 requests. Um... > I know keystores and .pem files are involved, but please give me > the big picture - what port does AJP need to run on, and where do I > go to find out how to tell it to use a “real" cert. Traditionally, AJP is run over port 8009 but you can always choose any port you wish as long as both sides of the connection (IIs, Tomcat) agree on which port to use. AJP is a non-secure protocol, full stop. You can tunnel it through other things but, as some have mentioned, since you are using localhost it's not super important to use encryption. > > Also I’ll have to figure out how to shut off port 8080 or require > SSL on tomcat once I get everything going. Actually I’d like to > limit Tomcat to responding to requests from the server itself. > Nothing should be talking to Tomcat but the isapi connector. -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5VoXkACgkQHPApP6U8 pFigog//bSaKIqRjLoNiyuoELd2PYcYx7Xw15sDxMXmI9/RziE8iECprRfUQhj47 EkUCe79vYa/Sowx72T4gsyZC/F76XRWMNuXKZjChkzQHBZtjStV/xdfi8NSKLLN4 e5qSFn9DtTwnQueLC91Uoq6sXaZ0ld2hRDBN0z1k3nTS+RK1t3BTjr63KLcyn/Ep RL386efU7HGESpcCNMJlh4Z6o12p6LNVhRF1nc/QYcaQW5dRElU5UJjW/trnuzsd JjUJtpdOdUO2FBkAlMyqvLlfj+OYOQ6rGQRhQP2VmqSUozp4EOekNrthQE3AWRVL 4eM1nRXhrmmBFGp7S1J49VELFqe8e+6RCvg1KNpSqLuKX+/UfN97IvGZd757fLdp T5jvMODuAztZyj1lgvU8se70B46cjSOSvsUXeiHUWppDAWUto5gwao66ry41UhRC 6sEP1UBhGvrXNs/w+mxW+3OuyTtey2wbtN5bydJulpi3w7sv5360sv56m9uJFEmn 3X1z0nyevkZySEuLJu12WPbGmbS9KJ6tpnZdpQ45q4124/1/2IbdsBxL8AKukAwn D0n8fTA9PRKYqA5iyQOHI/1hlcTYQKsPbmxd11ysnrnM6pFwstXq76rT00aEDMCB YhGARExsqqQUGf/Uusbzk14xcFX6vG4+ngVbMvXhmrx7SxMZOII= =a+rE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Good News! You can shut-off port 8080 by commenting out the HTTP Connector in the server.xml. Did you have the require SSL on the IIS Side? AJP doesn't use SSL, so it should work either way going thru IIS. Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Ellen Meiselman Sent: Tuesday, February 25, 2020 3:48 PM To: Tomcat Users List Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request > to > non-secire AJP. I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. I have had IIS set to require SSL, but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect. For example, this HTTP address does work. http://my.servers.domain.com/exposedApplication/simple.html <http://my.servers.domain.com/exposedApplication/simple.html> I never tried it because I knew I had set SSL to required. Sometimes you make assumptions that block progress. This HTTPS address does not work - I get the 403 from tomcat. https://my.servers.domain.com/exposedApplication/simple.html <http://my.servers.domain.com/exposedApplication/simple.html> So - if this makes sense to any of you, please tell me roughly what I need to do to make the AJP requests as secure as the port 80 requests. I know keystores and .pem files are involved, but please give me the big picture - what port does AJP need to run on, and where do I go to find out how to tell it to use a “real" cert. Also I’ll have to figure out how to shut off port 8080 or require SSL on tomcat once I get everything going. Actually I’d like to limit Tomcat to responding to requests from the server itself. Nothing should be talking to Tomcat but the isapi connector. Thanks, Ellen I > On Feb 25, 2020, at 4:07 PM, js84 wrote: > > Hello! > > What for are you using secret property when running tomcat locally using > loopback interface? > > I suggest to increase loglevel to „debug“ temporary. (Don’t forget to > reset it because performance will slow down dramatically if > isapi_redirect logfile grows on a Windows machine.) > > Best regards, > Johann > > Von: Christopher Schultz > Gesendet: Dienstag, 25. Februar 2020 21:42 > An: users@tomcat.apache.org > Betreff: Re: [OT] At wits end: Difficulties with IIS ISAPI connector > andTomcat > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Ellen, > > On 2/25/20 13:10, Ellen Meiselman wrote: >> No, just that I don't know how to set this particular connector up >> another way. I based this on the instructions on the isapi_connector >> site http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html >> and on the 2 older servers we have which are working.> I'm sort of >> thinking of suggesting that we get rid of IIS entirely and switch to >> Tomcat. Then we can run the necessary Java application and also serve >> all the HTML items we need to using the same web server. > Tomcat is a perfectly good "plain old" web server. Some security > people get all freaked-out when you suggest that Tomcat be exposed > "directly" but IMHO it can't be any worse than IIS. > > But also IMHO there are always reasons to use a reverse proxy: > flexibility and availability. When you are restarting Tomcat for > whatever reason, what will clients see if they try to access your > application? CONNECTION REFUSED? :( With the proxy in the way, that is > much less likely. Also, if you want to serve Java web applications, > python web applications, .NET whatevers, you'll be able to do that > much more flexibly with a reverse-proxy in the mix. > > - -chris > >> On Tue, Feb 2
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request > to > non-secire AJP. I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. I have had IIS set to require SSL, but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect. For example, this HTTP address does work. http://my.servers.domain.com/exposedApplication/simple.html <http://my.servers.domain.com/exposedApplication/simple.html> I never tried it because I knew I had set SSL to required. Sometimes you make assumptions that block progress. This HTTPS address does not work - I get the 403 from tomcat. https://my.servers.domain.com/exposedApplication/simple.html <http://my.servers.domain.com/exposedApplication/simple.html> So - if this makes sense to any of you, please tell me roughly what I need to do to make the AJP requests as secure as the port 80 requests. I know keystores and .pem files are involved, but please give me the big picture - what port does AJP need to run on, and where do I go to find out how to tell it to use a “real" cert. Also I’ll have to figure out how to shut off port 8080 or require SSL on tomcat once I get everything going. Actually I’d like to limit Tomcat to responding to requests from the server itself. Nothing should be talking to Tomcat but the isapi connector. Thanks, Ellen I > On Feb 25, 2020, at 4:07 PM, js84 wrote: > > Hello! > > What for are you using secret property when running tomcat locally using > loopback interface? > > I suggest to increase loglevel to „debug“ temporary. (Don’t forget to reset > it because performance will slow down dramatically if isapi_redirect logfile > grows on a Windows machine.) > > Best regards, > Johann > > Von: Christopher Schultz > Gesendet: Dienstag, 25. Februar 2020 21:42 > An: users@tomcat.apache.org > Betreff: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Ellen, > > On 2/25/20 13:10, Ellen Meiselman wrote: >> No, just that I don't know how to set this particular connector up >> another way. I based this on the instructions on the >> isapi_connector site >> http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html >> and on the 2 older servers we have which are working.> I'm sort of >> thinking of suggesting that we get rid of IIS entirely and switch >> to Tomcat. Then we can run the necessary Java application and also >> serve all the HTML items we need to using the same web server. > Tomcat is a perfectly good "plain old" web server. Some security > people get all freaked-out when you suggest that Tomcat be exposed > "directly" but IMHO it can't be any worse than IIS. > > But also IMHO there are always reasons to use a reverse proxy: > flexibility and availability. When you are restarting Tomcat for > whatever reason, what will clients see if they try to access your > application? CONNECTION REFUSED? :( With the proxy in the way, that is > much less likely. Also, if you want to serve Java web applications, > python web applications, .NET whatevers, you'll be able to do that > much more flexibly with a reverse-proxy in the mix. > > - -chris > >> On Tue, Feb 25, 2020 at 1:01 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >> Ellen, >> >> On 2/25/20 12:55, Ellen Meiselman wrote: >>>>> Sorry - no, the quotes were not there except for a 5 minute >>>>> test of a hopeless theory that they might be needed. Right >>>>> now there is no secret at all in the workers.properties, and >> in the >>>>> ajp connector, i have secretRequired ="false". >>>>> Workers.properties: worker.worker1.type=ajp13 >>>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>>> >>>>> Server.xml: >>>> address="127.0.0.1" port="8009" secretRequired="false" >>>>> redirectPort="8443" /> >> >> Hmm. I think we've all been operating under the assumption that >> the "secret" (by whatever name) was the source of the problem. It >> appears that was incorrect. >> >> Have a look at Jon's question about file permissions. >> >> Was this a configuration that had been working until recen
RE: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
What is in your URIWorkermap.properties file? Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Ellen Meiselman Sent: Tuesday, February 25, 2020 3:12 PM To: Tomcat Users List Subject: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat Hi Johann, I’ve been trying both ways - with and without secret. Happy to have it set up any way it works that won’t arouse the ire of our security team. I’ll increase the log levels and see what else I can find. Thanks, Ellen > On Feb 25, 2020, at 4:07 PM, js84 wrote: > > Hello! > > What for are you using secret property when running tomcat locally using > loopback interface? > > I suggest to increase loglevel to „debug“ temporary. (Don’t forget to > reset it because performance will slow down dramatically if > isapi_redirect logfile grows on a Windows machine.) > > Best regards, > Johann > > Von: Christopher Schultz > Gesendet: Dienstag, 25. Februar 2020 21:42 > An: users@tomcat.apache.org > Betreff: Re: [OT] At wits end: Difficulties with IIS ISAPI connector > andTomcat > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Ellen, > > On 2/25/20 13:10, Ellen Meiselman wrote: >> No, just that I don't know how to set this particular connector up >> another way. I based this on the instructions on the isapi_connector >> site http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html >> and on the 2 older servers we have which are working.> I'm sort of >> thinking of suggesting that we get rid of IIS entirely and switch to >> Tomcat. Then we can run the necessary Java application and also serve >> all the HTML items we need to using the same web server. > Tomcat is a perfectly good "plain old" web server. Some security > people get all freaked-out when you suggest that Tomcat be exposed > "directly" but IMHO it can't be any worse than IIS. > > But also IMHO there are always reasons to use a reverse proxy: > flexibility and availability. When you are restarting Tomcat for > whatever reason, what will clients see if they try to access your > application? CONNECTION REFUSED? :( With the proxy in the way, that is > much less likely. Also, if you want to serve Java web applications, > python web applications, .NET whatevers, you'll be able to do that > much more flexibly with a reverse-proxy in the mix. > > - -chris > >> On Tue, Feb 25, 2020 at 1:01 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >> Ellen, >> >> On 2/25/20 12:55, Ellen Meiselman wrote: >>>>> Sorry - no, the quotes were not there except for a 5 minute test >>>>> of a hopeless theory that they might be needed. Right now there is >>>>> no secret at all in the workers.properties, and >> in the >>>>> ajp connector, i have secretRequired ="false". >>>>> Workers.properties: worker.worker1.type=ajp13 >>>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>>> >>>>> Server.xml: >>>> address="127.0.0.1" port="8009" secretRequired="false" >>>>> redirectPort="8443" /> >> >> Hmm. I think we've all been operating under the assumption that the >> "secret" (by whatever name) was the source of the problem. It appears >> that was incorrect. >> >> Have a look at Jon's question about file permissions. >> >> Was this a configuration that had been working until recently, or is >> this a new configuration that you haven't (yet) been able to get >> working ? >> >> Any reason not to use HTTP(S) for your protocol instead of AJP? >> >> -chris >> >>>>> On Tue, Feb 25, 2020 at 12:35 PM Christopher Schultz < >>>>> ch...@christopherschultz.net> wrote: >>>>> >>>
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hi Johann, I’ve been trying both ways - with and without secret. Happy to have it set up any way it works that won’t arouse the ire of our security team. I’ll increase the log levels and see what else I can find. Thanks, Ellen > On Feb 25, 2020, at 4:07 PM, js84 wrote: > > Hello! > > What for are you using secret property when running tomcat locally using > loopback interface? > > I suggest to increase loglevel to „debug“ temporary. (Don’t forget to reset > it because performance will slow down dramatically if isapi_redirect logfile > grows on a Windows machine.) > > Best regards, > Johann > > Von: Christopher Schultz > Gesendet: Dienstag, 25. Februar 2020 21:42 > An: users@tomcat.apache.org > Betreff: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Ellen, > > On 2/25/20 13:10, Ellen Meiselman wrote: >> No, just that I don't know how to set this particular connector up >> another way. I based this on the instructions on the >> isapi_connector site >> http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html >> and on the 2 older servers we have which are working.> I'm sort of >> thinking of suggesting that we get rid of IIS entirely and switch >> to Tomcat. Then we can run the necessary Java application and also >> serve all the HTML items we need to using the same web server. > Tomcat is a perfectly good "plain old" web server. Some security > people get all freaked-out when you suggest that Tomcat be exposed > "directly" but IMHO it can't be any worse than IIS. > > But also IMHO there are always reasons to use a reverse proxy: > flexibility and availability. When you are restarting Tomcat for > whatever reason, what will clients see if they try to access your > application? CONNECTION REFUSED? :( With the proxy in the way, that is > much less likely. Also, if you want to serve Java web applications, > python web applications, .NET whatevers, you'll be able to do that > much more flexibly with a reverse-proxy in the mix. > > - -chris > >> On Tue, Feb 25, 2020 at 1:01 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >> Ellen, >> >> On 2/25/20 12:55, Ellen Meiselman wrote: >>>>> Sorry - no, the quotes were not there except for a 5 minute >>>>> test of a hopeless theory that they might be needed. Right >>>>> now there is no secret at all in the workers.properties, and >> in the >>>>> ajp connector, i have secretRequired ="false". >>>>> Workers.properties: worker.worker1.type=ajp13 >>>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>>> >>>>> Server.xml: >>>> address="127.0.0.1" port="8009" secretRequired="false" >>>>> redirectPort="8443" /> >> >> Hmm. I think we've all been operating under the assumption that >> the "secret" (by whatever name) was the source of the problem. It >> appears that was incorrect. >> >> Have a look at Jon's question about file permissions. >> >> Was this a configuration that had been working until recently, or >> is this a new configuration that you haven't (yet) been able to get >> working ? >> >> Any reason not to use HTTP(S) for your protocol instead of AJP? >> >> -chris >> >>>>> On Tue, Feb 25, 2020 at 12:35 PM Christopher Schultz < >>>>> ch...@christopherschultz.net> wrote: >>>>> >>>>> Ellen, >>>>> >>>>> On 2/25/20 12:06, Ellen Meiselman wrote: >>>>>>>> Yes, everything is on the same server. >>>>>>>> >>>>>>>> workers.properties: # Set properties for worker1 >>>>>>>> (ajp13) worker.worker1.type=ajp13 >>>>>>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>>>>>> worker.worker1.secret="mySecret". >>>>> >>>>> Just so there is no confusion: your "mySecret" should have >>>>> neither quotes nor the trailing period. >>>>> >>>>> Are those literally in your ISS config file? >>>>> >>>>> -chris >>>>> >>>>>>>> On Tue, Feb 25, 2020 at 11:27 AM >>>>>>>> wrote: >>>>>>>> >>>>>>>>> -Original Message- From:
AW: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hello! What for are you using secret property when running tomcat locally using loopback interface? I suggest to increase loglevel to „debug“ temporary. (Don’t forget to reset it because performance will slow down dramatically if isapi_redirect logfile grows on a Windows machine.) Best regards, Johann Von: Christopher Schultz Gesendet: Dienstag, 25. Februar 2020 21:42 An: users@tomcat.apache.org Betreff: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, On 2/25/20 13:10, Ellen Meiselman wrote: > No, just that I don't know how to set this particular connector up > another way. I based this on the instructions on the > isapi_connector site > http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html > and on the 2 older servers we have which are working.> I'm sort of > thinking of suggesting that we get rid of IIS entirely and switch > to Tomcat. Then we can run the necessary Java application and also > serve all the HTML items we need to using the same web server. Tomcat is a perfectly good "plain old" web server. Some security people get all freaked-out when you suggest that Tomcat be exposed "directly" but IMHO it can't be any worse than IIS. But also IMHO there are always reasons to use a reverse proxy: flexibility and availability. When you are restarting Tomcat for whatever reason, what will clients see if they try to access your application? CONNECTION REFUSED? :( With the proxy in the way, that is much less likely. Also, if you want to serve Java web applications, python web applications, .NET whatevers, you'll be able to do that much more flexibly with a reverse-proxy in the mix. - -chris > On Tue, Feb 25, 2020 at 1:01 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Ellen, > > On 2/25/20 12:55, Ellen Meiselman wrote: >>>> Sorry - no, the quotes were not there except for a 5 minute >>>> test of a hopeless theory that they might be needed. Right >>>> now there is no secret at all in the workers.properties, and > in the >>>> ajp connector, i have secretRequired ="false". >>>> Workers.properties: worker.worker1.type=ajp13 >>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>> >>>> Server.xml: >>> address="127.0.0.1" port="8009" secretRequired="false" >>>> redirectPort="8443" /> > > Hmm. I think we've all been operating under the assumption that > the "secret" (by whatever name) was the source of the problem. It > appears that was incorrect. > > Have a look at Jon's question about file permissions. > > Was this a configuration that had been working until recently, or > is this a new configuration that you haven't (yet) been able to get > working ? > > Any reason not to use HTTP(S) for your protocol instead of AJP? > > -chris > >>>> On Tue, Feb 25, 2020 at 12:35 PM Christopher Schultz < >>>> ch...@christopherschultz.net> wrote: >>>> >>>> Ellen, >>>> >>>> On 2/25/20 12:06, Ellen Meiselman wrote: >>>>>>> Yes, everything is on the same server. >>>>>>> >>>>>>> workers.properties: # Set properties for worker1 >>>>>>> (ajp13) worker.worker1.type=ajp13 >>>>>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>>>>> worker.worker1.secret="mySecret". >>>> >>>> Just so there is no confusion: your "mySecret" should have >>>> neither quotes nor the trailing period. >>>> >>>> Are those literally in your ISS config file? >>>> >>>> -chris >>>> >>>>>>> On Tue, Feb 25, 2020 at 11:27 AM >>>>>>> wrote: >>>>>>> >>>>>>>> -Original Message- From: Ellen Meiselman >>>>>>>> Sent: Tuesday, February 25, 2020 >>>>>>>> 10:01 AM To: Tomcat Users List >>>>>>>> Subject: Re: At wits end: >>>>>>>> Difficulties with IIS ISAPI connector and Tomcat >>>>>>>> >>>>>>>>> Hi, >>>>>>>> >>>>>>>>> I've been testing, and so far, there is no change >>>>>>>>> in the behavior. I am >>>>>>>> still getting the same tomcat->based 403 error. >>>>>>>> >>>>>>>>> Based on what you said above... >>>>>>>>&
AW: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hello! What for are you using secret property when running tomcat locally using loopback interface? I suggest to increase loglevel to „debug“ temporary. (Don’t forget to reset it because performance will slow down dramatically if isapi_redirect logfile grows on a Windows machine.) Best regards, Johann Von: Christopher Schultz Gesendet: Dienstag, 25. Februar 2020 21:42 An: users@tomcat.apache.org Betreff: Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, On 2/25/20 13:10, Ellen Meiselman wrote: > No, just that I don't know how to set this particular connector up > another way. I based this on the instructions on the > isapi_connector site > http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html > and on the 2 older servers we have which are working.> I'm sort of > thinking of suggesting that we get rid of IIS entirely and switch > to Tomcat. Then we can run the necessary Java application and also > serve all the HTML items we need to using the same web server. Tomcat is a perfectly good "plain old" web server. Some security people get all freaked-out when you suggest that Tomcat be exposed "directly" but IMHO it can't be any worse than IIS. But also IMHO there are always reasons to use a reverse proxy: flexibility and availability. When you are restarting Tomcat for whatever reason, what will clients see if they try to access your application? CONNECTION REFUSED? :( With the proxy in the way, that is much less likely. Also, if you want to serve Java web applications, python web applications, .NET whatevers, you'll be able to do that much more flexibly with a reverse-proxy in the mix. - -chris > On Tue, Feb 25, 2020 at 1:01 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Ellen, > > On 2/25/20 12:55, Ellen Meiselman wrote: >>>> Sorry - no, the quotes were not there except for a 5 minute >>>> test of a hopeless theory that they might be needed. Right >>>> now there is no secret at all in the workers.properties, and > in the >>>> ajp connector, i have secretRequired ="false". >>>> Workers.properties: worker.worker1.type=ajp13 >>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>> >>>> Server.xml: >>> address="127.0.0.1" port="8009" secretRequired="false" >>>> redirectPort="8443" /> > > Hmm. I think we've all been operating under the assumption that > the "secret" (by whatever name) was the source of the problem. It > appears that was incorrect. > > Have a look at Jon's question about file permissions. > > Was this a configuration that had been working until recently, or > is this a new configuration that you haven't (yet) been able to get > working ? > > Any reason not to use HTTP(S) for your protocol instead of AJP? > > -chris > >>>> On Tue, Feb 25, 2020 at 12:35 PM Christopher Schultz < >>>> ch...@christopherschultz.net> wrote: >>>> >>>> Ellen, >>>> >>>> On 2/25/20 12:06, Ellen Meiselman wrote: >>>>>>> Yes, everything is on the same server. >>>>>>> >>>>>>> workers.properties: # Set properties for worker1 >>>>>>> (ajp13) worker.worker1.type=ajp13 >>>>>>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009 >>>>>>> worker.worker1.secret="mySecret". >>>> >>>> Just so there is no confusion: your "mySecret" should have >>>> neither quotes nor the trailing period. >>>> >>>> Are those literally in your ISS config file? >>>> >>>> -chris >>>> >>>>>>> On Tue, Feb 25, 2020 at 11:27 AM >>>>>>> wrote: >>>>>>> >>>>>>>> -Original Message- From: Ellen Meiselman >>>>>>>> Sent: Tuesday, February 25, 2020 >>>>>>>> 10:01 AM To: Tomcat Users List >>>>>>>> Subject: Re: At wits end: >>>>>>>> Difficulties with IIS ISAPI connector and Tomcat >>>>>>>> >>>>>>>>> Hi, >>>>>>>> >>>>>>>>> I've been testing, and so far, there is no change >>>>>>>>> in the behavior. I am >>>>>>>> still getting the same tomcat->based 403 error. >>>>>>>> >>>>>>>>> Based on what you said above... >>>>>>>>&
