In any situation where information needs injecting into part of an app, remember the "tell, don't ask" principle.
If you pass configuration into the business logic layer directly, then you are creating a coupling between the two. It becomes difficult to change the configuration without breaking the business logic layer. Further, you potentially create the need to have to mock the configuration for testing purposes.
However, having to pass individual configuration values as parameters into every business layer method call from the web layer creates other problems. It adds extra complexity to those method signatures and ceremony to using them and it also necessitates exposing all of the configuration to all of the web layer. Again, remember "tell, don't ask": parts of the web layer should only be told about those aspects of configuration that they need to know about.
So I'd suggest a third approach. Inject the configuration values required by each class within the business logic layer, as parameters to their constructors. That way it becomes the responsibility of your IoC framework, if you are using one (or your dependency mapping code at app start if you are using pure DI) to route individual values to just those classes that need them.