Creating a *.local ssl certificate
You added SAN to the CSR but you didn't tell ca to include extensions from the CSR in the certificate. See
https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate or the man page for ca also on the web at copy_extensions
EDIT: You also need to specify x509_extensions in the ca config, or equivalent but less convenient the commandline option -extensions, in either case pointing to a section that exists but can be empty if you don't want any CA-required extensions. I didn't notice this at first because I had never tried the case of extensions from CSR only and not config, which is unrealistic for most CAs. If you specify copy_extensions other than none (and the CSR has some) but don't specify x509_extensions then ca does put the extensions in the cert but does not set the cert version to v3 as is required by standards (like rfc5280) when extensions are present.
It's arguable if this is a bug; the manpage says x509_extensions/extensions controls the v3 setting, and by not saying any similar thing about copy_extensions implies that does not, but IMHO it's certainly a very suboptimal feature. EDIT: it is a bug and will be fixed but until then use the workaround, see https://unix.stackexchange.com/a/394465/59699
HOWEVER: in my test, this didn't actually solve your problem. Even though the cert has *.local in SAN and CN and is (now) otherwise valid, my Firefox (53.0.2) and Chrome (59.0.3071.109) still reject it with SSL_ERROR_CERT_DOMAIN_ERROR and ERR_CERT_COMMON_NAME_INVALID respectively. I guessed they might not be excluding local from the normal 2+-level logic and tried *.example.local: Chrome does accept that, but Firefox doesn't. I also tried *.example.org and both Chrome and IE11 like that but still not Firefox (and of course assigning yourself names in real TLDs like .org is not the way DNS is supposed to work).
This has me stuck. With some work OpenSSL can be made to generate a cert containing almost anything you want, but what Firefox and Chrome will accept I do not know. I will try to look into that and update if I find anything.
I hope you mean you gave *.local as the CommonName only for the server CSR and NOT for the CA (self-signed) cert. If Subject names for CA and leaf certs are the same nothing will work reliably. EDIT: your edited Q confirms they were correctly different. Although it does not mention also specifying Country, State, and Organization as is required by the ca policy you used.
Note 'self-signed' is a term of art and means signed with the same key. Your CA cert is self-signed. Your server cert is signed by you yourself using your own key but it is not self-signed. Trying to apply instructions for a self-signed cert to a not-self-signed cert was part of your problem.
And Gilles point about md5 for the signature algorithm is also correct.
EDIT: 'resetting' serial (and index) for an openssl ca setup is a bad idea, unless you permanently discard the CA cert and name they were used for. The standards say a given CA must not issue more than one cert with the same serial value in the cert, and the serial file is the way openssl ca (and also x509 -req) implements this. 'Real' (public) CAs nowadays no longer use a simple counter but include entropy to block collision attacks on PKI -- google hashclash -- but this is not an issue for a personal CA like yours. I can readily believe a browser (or other relier) being unhappy if it sees multiple certs with the same serial and CA name, although I would NOT expect a browser to persistently store a leaf cert -- and thus see both the old and new ones in one process unless long-running -- unless you import it to the applicable store, including in Firefox if you make it a permanent 'exception'.
Wildcard certificates are not permitted for a top-level domain like .local or .com and they aren't accepted by Firefox or IE either. https://crbug.com/736715.