I'm going to suggest that your CEO rages because he feels impotent. He can see that things are not working, and he knows that he has limited to no ability to change that fact. He is frustrated by his inability to will his company to success. If this is true, then I propose that the best way to calm him down is to give him total visibility into your team and process. Throw open the doors and say: "You must give me this week. Every day this week, you will spend the entire day with my team. You will go to every meeting, you will sit with every developer and manager, and you will see how the sausage is made. Push back all your other commitments."
Then, do exactly that. Invite him to your planning meetings, your status meetings, your standups (assuming you have them). Have enough developers "pair" with him so that he can see what they do all day. Tell him to ask what problems are holding them back. He doesn't have to understand how the code is written, but he has to understand the frustrations and limitations that the dev team faces on a daily basis. Only when you immerse him in the actual process can he see that there are deeply rooted issues that need to be resolved. He needs to have this interaction:
"Ok, what are you doing now?"
"Well, I'm working on this bug. See this ticket? Ok, it says when you push button X in app Y, you get this error message. So first I'm gonna open up app Y and see if I can repro it."
"Yeah, I get that. I've used app Y before. It's kinda janky and does random stuff."
Developer frowns. "Yeah, well, we tried to write some acceptance tests for it, but there's always new feature requests coming in, so... Ok. The app is loaded. Let me set up the repro case...ok, now when I click this button...boom! Yup. Bug is reproed."
"Ok, now what? How do you fix it?"
"Well, that's the hard part. Now I have to start up app Y on my machine here and attach a debugger..."
"Yeah, it kinda is. Anyway, there should be some unit tests which cover button X, but we never got around to that either."
"What are unit tests?"
"Well, they are very small tests which check the smallest bit of functionality in each part of the program, so you can quickly find bugs."
"So you're saying we can't quickly find this bug because you don't have these tests?"
"Yeah, that's why I have to attach a debugger. We might get lucky and I might figure it out in like 10 minutes, or I might spend the next 4 hours trying to figure it out."
"We can't spend that kind of time fixing a bug!!!"
Dev cowers in fear. "Well, sir...umm....I hate to tell you this, but...most bugs take at least that long to fix..."
"THIS IS UNACCEPTABLE!!!"
At this point, you get to explain to the CEO the concept of technical debt, and why he absolutely needs to support you in paying this down (say, 20-25% of your total resource allocation). But you also get to explain that as you pay it down, feature velocity will increase, because it's always easier to add features to a well-maintained system than a Rube Goldberg system.
After you get the CEO on your side, you can then proceed to gather all the stakeholders/product owners and review your org's product backlog together, explaining that everyone needs to agree on the importance and priority of each project that your org works on. Your team cannot magically deliver 5 projects at once. Your team is flexible and can change what they work on as business requirements demand, but this will incur a cost. At the end of the day, all the product owners can do is change the order of the backlog, not demand that everything move faster. If they want to impose a deadline, then they must accept whatever is ready by the deadline. If they want to demand a feature, then they must give up a hard deadline. And, of course, remind them that 20-25% of your team is always allocated to pay down tech debt, until it reaches sustainable levels.
You said that you have a bunch of junior engineers and you like your team. What worries me is that you didn't say: "Fortunately, I also have a handful of very experienced developers who can set best practices and mentor the juniors." You mentioned that you have senior developers, but not that they are good. At this point, you have to take a very hard look at your team and ask yourself: "Do I have any really good developers? Do I have any rock stars?" And if the answer is: "No", then that is your next order of business. You need to find one or three and hire them. In this economy, that should be easier than 9 months ago. Explain to the CEO that this is essential to improve code quality and delivery speed.
The fact that you built up massive tech debt in the first place tells me that you do not have any key, reliable, solid engineers you can lean on to lead the cleanup effort. If you are having to lead the charge on code quality yourself, as management, then that is a very bad sign. When you are hiring, you need to keep an eye out for engineers that specifically call out quality practices on their resume, like TDD, unit testing, refactoring, design reviews, etc. Anything which indicates that they are not just code cowboys trying to win high score on PRs per day. And you need to make clear that you need people who are not just great coders and experienced engineers who can define best practices and set standards for the team, but also teachers and mentors who can skill up the rest of the team in pair programming, seminars, tech talks, and the like.
You can't expect junior engineers to just magically get better on their own. That takes years. You don't have years to skill up your team. You have months at best, maybe not even that. If there are any user groups in your area which hold tech talks on tech debt/code quality/etc., pay for your team to attend, or invite speakers to your office to share principles, techniques, tools, etc. Make sure they can bring high-quality open-source repos to show and tell to illustrate what a well-maintained codebase looks like, and how you keep it that way.
Make a list of 5-10 good technical books in the language you use for production that highlights best practices for that language, as well as good testing and release practices, and create a small technical library for your team. Encourage your team to check out/read the books, and get the CEO to approve a modest training budget to cover books/seminars/in-house speakers/etc.
Often times, what you need is an engineer who has worked in a big tech company that does a lot of things right. That person will have absorbed good practices via the company culture, and can evangelize those practices throughout your team. Getting such a person might be expensive, but if they improve your whole team by 10%, then they will quickly pay for themselves (assuming you have more than 10 devs). You need an engineer that models ideal development behavior, teaches it to willing junior devs, and evangelizes it to the team on a proactive basis. Even just one good dev like this can turn your whole team around, as long as they are hungry to learn and improve.
I know this is a lot for you to demand, and many of these moves are politically risky. You have to use your own judgment to decide what you can and cannot pull off. It's a difficult position, but also one filled with possibility if you can turn things around. Good luck!