Assuming due dates are per-item, then no, there's no math that would translate that into a sum of known quantities that could be burned down to zero over the course of a sprint. You could burn down items remaining, and any item that misses its due date doesn't burn down, but this is hard on the team and dangerous to the project. Once an item misses its due date, the team will have no motivation to continue working on it and will move to other tasks they can still get credit for completing on time.
You could perhaps hijack the estimated time vs actual time burn-down model, where estimated time is the number of days from the start of the sprint until that due date. This keeps the tracked value on the item 'alive' and prevents the deprioritization above.
I'm a little concerned, though, that you're breaking a fundamental principle of scrum: the only due date is the end of the sprint. The team takes on a stack of work at the start of a sprint and promises to have it completed by the end. If due dates are a problem, assign work to sprints that end before those dates. Use one-week sprints if work is coming in so rapidly that you need to make sure it gets into a sprint early enough. If even that isn't rapid enough, then maybe scrum isn't for you, and you should stop doing it. Jamming scrum into that kind of environment leads to failure all too easily.
Perhaps look into pure pull-based kanban, and put the nearest-due date items at the top of the pile. The trick is to get into a position where due dates aren't at the front of your mind. If you're always racing to meet them, something is wrong, and charts won't fix it.
Lastly, I'd recommend getting your management together to talk about the state of scrum at your company. Either they aren't really doing scrum and think they are, or the team you're on has a broken implementation and needs to be corrected by others at the company who know better. Hopefully it's just the latter, because if it's the former, hoo boy. Nothing spells doomed quite like a company that thinks it can pick and choose the parts of scrum it likes and leave out the rest. Remember: frankenscrum and waterscrum aren't real. They're just myths agile coaches made up to calm managers down while they subvert them from the ground up. You aren't supposed to actually do them!