MongoDB Documentation, Release 3.0.4 MongoDB 2.4 User Model Removed MongoDB 3.0 completely removes support for the deprecated 2.4 user model. MongoDB 3.0 will exit with an error message if there is user data with the 2.4 schema, i.e. if authSchema version is less than 3 . To verify the version of your existing schema, query the system.version collection in the admin database: use admin db.system.version.find() If you are currently using auth , the query returns the currentVersion of the existing authSchema . If you are not currently using auth , the query will not return any result, and you do not need to take any actions regarding the authSchema version. If, however, the current authSchema version is less than 3 , see Upgrade User Authorization Data to 2.6 Format (page 870) to upgrade to the 2.6 user model before upgrading to 3.0. After upgrading MongoDB to 3.0 from 2.6, to use the new SCRAM-SHA-1 challenge-response mechanism if you have existing user data, you will need to upgrade the authentication schema a second time. This upgrades the MONGODB-CR user model to SCRAM-SHA-1 user model. See Upgrade to SCRAM-SHA-1 (page 818) for details. Localhost Exception Changed In 3.0, the localhost exception changed so that these connections only have access to create the first user on the admin database. In previous versions, connections that gained access using the localhost exception had unrestricted access to the MongoDB instance. See Localhost Exception (page 324) for more information. db.addUser() Removed 3.0 removes the legacy db.addUser() method. Use db.createUser() and db.updateUser() instead. TLS/SSL Configuration Option Changes MongoDB 3.0 introduced new net.ssl.allowConnectionsWithoutCertificates configuration file setting and --sslAllowConnectionsWithoutCertificates command line option for mongod and mongos . These options replace previous net.ssl.weakCertificateValidation and --sslWeakCertificateValidation options, which became aliases. Update your configuration to en- sure future compatibility. TLS/SSL Certificates Validation By default, when running in SSL mode, MongoDB instances will only start if its certificate (i.e. net.ssl.PemKeyFile ) is valid. You can disable this behavior with the net.ssl.allowInvalidCertificates setting or the --sslAllowInvalidCertificates command line option. To start the mongo shell with --ssl , you must explicitly specify either the --sslCAFile or --sslAllowInvalidCertificates option at startup. See TLS/SSL Configuration for Clients (page 346) for more information. TLS/SSL Certificate Hostname Validation By default, MongoDB validates the hostnames of hosts attempting to connect using certificates against the hostnames listed in those certificates. In certain deployment situations this behavior may be undesirable. It is now possible to disable such hostname validation without disabling val- idation of the rest of the certificate information with the net.ssl.allowInvalidHostnames setting or the --sslAllowInvalidHostnames command line option. SSLv3 Ciphers Disabled In light of vulnerabilities in legacy SSL ciphers$^{231}$, these ciphers have been explicitly disabled in MongoDB. No configuration changes are necessary. $^{231}$https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 12.1. Current Stable Release 807