about testrfc7030.com server 443 port

[WKJay]

Hi

I am currently testing my est protocol use the server deployed on http://www.testrfc7030.com/. But I have encountered some problems.

At first I used libest/example/server to create a est server on my computer. All configurations are default.Then I used my own client (not libest example client) to connect my est server and it worked fine. You should know that I implemented the TLS channel binding value in the challengePassword attribute in PKCS10 request. My est server accepted the request, verified challengePassword and successfully generated the final certification.

But when I used the server on http://www.testrfc7030.com/ and sent the same request, my request failed and returned error code 400.Then I used libest simple client, it worked. After that , I tried to use my clinet (not libest example client) and removed challengePassword attribute and sent to port 8443, it worked too.

I know when I add challengePassword attribute, the server must verify it. So if my challengePassword is incorrect, the server would reject my request.But my est server accepted my request which means my challengePassword was correct. So why testrfc7030.com rejected my request.

Can anyone give me a hint what might cause this problem? Or are there any testrfc7030.com server configuration details that I can use to build the same test server as testrfc7030.com,so that I could test by my own ?

Thanks, Jay

[rpb5bnc]

Hi Jay,

The same day you posted this issue (Friday 11/13) our automated test also failed a few hours later. I haven't had a chance to study exactly why it failed, but it has run again this morning (Monday 11/16) and it's back to passing. I didn't develop our automated test of testrfc7030.com, but I quite sure it tests all three ports.

The day you posted this issue I also attempted an enroll from my system to 443 and it also failed the same way. I didn't get a change to investigate any further at that time.

Today I downloaded the logs from the 443 server instance. I could see this instance successfully enrolling certs right up until Friday morning, your enroll requests included, that is assuming this is your subject line, Subject: CN=WKJay I saw a number of failures on Friday, presumably from you and others including my attempts.

I've since seen successful enrollments again starting today, Monday 11/16.

At the moment I believe this was a temporary failure, possibly due to something happening in AWS, maybe something with respect to a TLS proxy.

If you see this again, just let us know and I'll look into it further.

Regards, Pete

[WKJay]

Hi Pete,

Thanks for your replay and thanks a lot for your work.

The requests including subject line CN=WKJay were indeed my requests. I used both my own est clinet and libest client-simple to test , so maybe all successful requests were from libest example client beacause it always gets successful response.

Today I used my own client to test again ( 433 port ), and I have changed my subject line CN to WKJay-newTest . On my side it still failed. Maybe you can check today's logs and find CN=WKJay-newTest requests. If these requests were success on your server, then we could assume something with respect to a TLS proxy caused these problems. But if these requests also failed on your server then maybe my requests were not correct and we can figure out what exactly triggered these failures through logs.

Thanks again for your support : )

Regards, Jay

[rpb5bnc]

Hi Jay,

First, I hope my response here is not even needed and that you've already resolved this issue and have since moved on. If that's not the case, I finally found time to get back to this.

I cloned this latest libest code and built it on my system. I went through the steps to perform an enrollment through port 443 on testrfc7030.com and the enrollment was successful. We also have a nightly Jenkins job that tests the availability of all three instances of estserver on testrfc7030.com and this job has been passing for a while now.

I then ran estclient and estserver locally, performed an enrollment between the two, and verfied that the TLS UID that is obtained and included in the CSR on the client side matched what the estserver was seeing for the TLS UID on its side.

If you have not yet resolved your issue I would say that at this point it has something to do with your client, or possibly something to do with your side of the network connection between your client and testrfc7030.com. I believe a TLS proxy node could cause issues by terminating the TLS connection with your client and then starting a up a new one to go to testrfc7030.com. The TLS UID obtained by the EST server code at testrfc7030.com would of course not be the same as the one the client obtained and added into the CSR since they are on two different TLS connections in this situation. At this point this is about all I can guess might be going wrong for you.

Sorry I could not be of more help. Pete

[WKJay]

Hi Pete,

I think the problem was actually caused by a proxy since I used libest latest code to build a server on my side and it worked fine.

Thanks any way for your work and support.

Regards, Jay