Technically, you improve the security a little, but to no useful end.
Random numbers usually come from a pseudo-random number generator (PRNG) that is itself seeded with a random value. The purpose of the PRNG is to stretch the original seed to produce a very long output. Random numbers are usually invoked for two reasons:
To create random-looking data for somewhat casual use. Perhaps to give characters in a video game a random-looking strategy, maybe to run a randomized algorithm, etc. The general requirement is that the random values be well distributed and pass basic statistical tests, although the exact usage dictates exactly what the requirements are.
To provide cryptographic security. Perhaps to generate a secret key, to start the search for a random prime number, etc. The requirement is that the random values be very well distributed, pass many advanced statistical tests, have a very large seed space, and yield no information about other values in the output or anything about the seed of the PRNG.
PRNGs are usually designed for one of those requirements, and they are nothing alike. The PRNGs for casual use tend to be very simple, extremely fast, and meet none of the requirements of a cryptographic PRNG. It's very difficult turn a simple PRNG into a cryptographic PRNG; in order to do so there would likely be very little resembling the original PRNG left in the final secure PRNG scheme.
Here are some the problems with combining the weak PRNGs:
Period length. When you combine two PRNGs linearly (like in the OP) you will at best combine their seed lengths. Simple PRNGs generally have 32 bits or less of seed length, which is cryptographically very insecure. You should generally have at least 128 bits of seed space.
Seed protection. Combining the PRNG outputs won't necessarily prevent the seed from being reverse-engineered from the PRNG output. If an attacker can derive part of the seed, they can reduce their work load drastically. Deriving the seed from the output of a simple PRNG is sometimes trivial in proper circumstances.
Output bias. Linearly combining the PRNG outputs won't necessarily hide their flawed outputs. It should definitely improve the bias, but it is unlikely that they will be as good as a cryptographic PRNG. (Practically, this is probably less of a concern, but still worth mentioning.)
And that's assume you seed the PRNG properly. You still need to do that seeding manually as whatever default seeding the simple PRNGs use is probably based on something very low quality, like a timestamp.
The simple summery is that combining weak PRNGs provides better security, but not the level of security you should expect from a cryptographically secure PRNG. The solution is to get a real cryptographic PRNG and seed it with random data from a good source, like
CryptGenRandom(). Or you could just use the output of those directly since they are technically PRNGs themselves seeded by other random data.
openssl_random_pseudo_bytes sets the flag indicating that it did not generate secure random bytes, that would seem like there is something wrong with the environment because the manuals suggest that it should be expected to return
true under normal conditions. Check to see what version of PHP / OpenSSL is installed and whether you can update it. If you can't get it to work, consider just getting your random data directly from