Nit picks about these certificates:
The certificates have a lifetime of 10 years starting from the exact moment they're created. I suspect ten years is overkill, but I don't see much real harm in it. However it's common practice to set the notBefore into the recent past, this is because a variety of problems may cause clock drift. This is your development environment, so you _could_ fix any drift, but this sort of tool is all about productivity, so I think "back dating" by one day or even an hour to allow for drift would be a sound idea.
The EKU says TLS Server, I'd be tempted to throw TLS Client in there too. It would appear tempting to say anyUsage, but actually some peers will decide this is overbroad and reject your certificate so don't do that. But having TLS Client might be nice if anybody is working on mutual authentication (both client and server present certificates, not very friendly for B2C apps but I like it in B2B).
The Key Usage says Key Encipherment and Digital Signature. Again it's harmless in a development environment, but security-oriented live systems ought to contemplate removing Key Encipherment.
The only reason you'd need Key Encipherment in TLS is because you're doing RSA key agreement, which means you aren't getting Forward Secrecy by definition and you're probably using some pretty rusty components. So it could make sense to spot that "Oops, we're trying to do RSA key agreement - why?" in a development system before you ship it and discover you're offering radically less security than you expected for some reason.