Closed Bug 1450719 Opened 8 years ago Closed 8 years ago

autocert: implement check for reissue_processing before attempting cert download

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Product:
Infrastructure & Operations Graveyard
Component:
WebOps: Other
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sidler, Assigned: sidler)

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/6432])

No description provided.
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/6432]
Assignee: server-ops-webops → sidler
https://www.digicert.com/services/v2/order/certificate?filters[status]=reissue_processing Here are some output logs of my automation attempting to use the REST api above to determine if an order is still in 'reissue_processing'. I run the command in a loop trying to get the orders that are still in 'reissue_processing' and checking my order_id(s) against that list. That line will look something like this: 2018-04-03 15:17:58,710 - api - DEBUG - FIXME: are any of order_ids=(2781349,) in processing_ids=[2781349, 2781317, 2781288, 2781259, 2651978] => True At the beginning of every loop I log the return code, the url hit with GET, and json if possible, if not the text of the response. A successful response will look like this: api_1 | 2018-04-03 15:17:52,316 - api - DEBUG - FIXME: status=200 url=https://www.digicert.com:443/services/v2/order/certificate?filters[status]=reissue_processing api_1 | 2018-04-03 15:17:52,316 - api - DEBUG - {'orders': [{'id': 2781349, 'certificate': {'id': 2283180, 'common_name': 'spandex-galley.tercotua.org', 'dns_names': ['spandex-galley.tercotua.org', 'n1.tercotua.org', 'n2.tercotua.org'], 'valid_till': '2018-04-06', 'signature_hash': 'sha256'}, 'status': 'reissue_processing', 'is_renewed': False, 'date_created': '2018-04-03T15:17:43+00:00', 'organization': {'id': 147486, 'name': 'Mozilla Corporation'}, ... REDACTED FOR BREVITY A failure response will look like this: api_1 | 0:00:19.563009 < 0:01:30; repeat 7 api_1 | 2018-04-03 15:18:14,598 - api - DEBUG - FIXME: status=403 url=https://www.digicert.com:443/services/v2/order/certificate?filters[status]=reissue_processing api_1 | 2018-04-03 15:18:14,599 - api - DEBUG - <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> api_1 | <html><head> api_1 | <title>403 Forbidden</title> api_1 | </head><body> api_1 | <h1>Forbidden</h1> api_1 | <p>You don't have permission to access /services/v2/order/certificate api_1 | on this server.</p> api_1 | <script type="text/javascript"> api_1 | //<![CDATA[ api_1 | (function() { api_1 | var _analytics_scr = document.createElement('script'); api_1 | _analytics_scr.type = 'text/javascript'; _analytics_scr.async = true; _analytics_scr.src = '/_Incapsula_Resource?SWJIYLWA=719d34d31c8e3a6e6fffd425f7e032f3&ns=7&cb=655140478'; api_1 | var _analytics_elem = document.getElementsByTagName('script')[0]; _analytics_elem.parentNode.insertBefore(_analytics_scr, _analytics_elem); api_1 | })(); api_1 | // ]]> api_1 | </script></body></html> I am also concerned on how long it takes to get orders through 'reissue_processing'. In a ipython shell I kept running the following python command, over and over: In [155]: call = da.get(path='https://www.digicert.com:443/services/v2/order/certificate?filters[status]=reissue_processing'); [order.id for order in call.recv.json.orders] Out[155]: [2781594, 2651978] 10 mins later the order 2781594 had not moved out of 'reissue_processing'. Another issue that should be resolved but is not super important to understanding this flow, is that order_id 2651978 has been stuck in 'reissue_processing' for days now. Why can that happen? What is the expected turn around time of the reissue process? Why are reissue orders getting stuck in state? This workflow really sucks. Is DigiCert going to do anything about this? It seems to me that there is a large bug in your REST api when you can request a reissue, but allow downloads of the old certificate. Putting the onus on a customer like me to try an block for this isn't user friendly and as you can see is not easy to achieve. Thanks, Scott Idler P.S. I checked again, that order is still in the 'reissue_processing' state, some 20mins later...
Scott, I appreciate your feedback. I agree that the fact that the API is returning the old certificate and that there isn’t a good way to deal with that is a problem. I have messaged our product management team to see if it is possible to change the behavior of our system in this situation so that the old certificate does not get returned and mess up the workflow. I will let you know what I hear back. Jared Mensinger
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.