foreword
There is a project in the department that involves sending emails. The sending function can be successfully sent in the local test, but when it is packaged and deployed in the docker environment, it appears
No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
After searching the Internet, I found this article
An answerer in this article mentioned that he used the version of jdk 8u292, which has disabled the insecure TLSv1&TLSv1.1, so I checked the jdk version of the docker base image we deployed, which is jdk8u332. I searched for solutions later. Most of the solutions are solved by modifying the jdk.tls.disabledAlgorithms configuration in the java.security file and deleting TLSv1&TLSv1.1
But this kind of plan gives me the feeling that there is something wrong. After all, it should be considered that jdk disables TLSv1&TLSv1.1. So from the beginning, I took this solution as the final solution when other solutions could not solve it. Let's review my solution process
Solution process
Solution 1: Configure mail.smtp.ssl.protocols as TLSv1.2
But after the modification, the following exception was reported
The server selected protocol version TLS10 is not accepted by client preferences [TLS12]
Because the server side supports TLSv1.0, so no trick, mail.smtp.ssl.protocols cannot be changed to TLSv1.2
Solution 2: Replace the javax.mail package with com.sun.mail
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
<version>1.6.2</version>
</dependency>
The source of this solution is the following blog post
https://blog.csdn.net/qq_33601179/article/details/123069499
He solved it by adjusting the gav of the mail, but after experimenting, I found that this solution did not solve my problem and still reported
No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
Solution 3: Enter the docker container, modify the jdk.tls.disabledAlgorithms configuration in the java.security file, and delete TLSv1&TLSv1.1
I checked the information on the Internet, most of them modify java.security through the host machine, and modify it through docker, but basically I don’t see it.
But we can modify it by entering the inside of the container docker. But to modify java.security, you must first know the location of the java.security file. The location of the java.security file may be different for different base images.
So how do you know the specific location of java.security? Here is an idea. If it is a self-made basic image, you can ask the author of the self-made image. If it is a public image, you can use docker hub. For example, the image of our project uses skywalking-java-agent:8.11 .0-java8, so we can go to the docker hub, search for the image, and then click on the details, some of which will have IMAGE LAYERS.
From this, we can know the basic path of java, and then enter the container
We can use the vim command to modify the contents of the java.security file, but when modifying normally, we need to install vim
apt-get update
apt-get install vim
Restart the container after modification, and then access ip:port/actuator/health, the premise is to introduce actuator
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
and configure
endpoint:
health:
show-details: always
Check the health status of the mail
or send a test mail directly, and verify it
Solution 4: Adjust Dockerfile
In fact, the implementation logic of Solution 4 is the same as that of Solution 3. The core is to modify the jdk.tls.disabledAlgorithms configuration in the java.security file and delete TLSv1&TLSv1.1. But the disadvantage of the third solution is that after each release, you have to re-enter the docker container to modify it. The fourth solution is
to add the following content in the Dcokerfile file
RUN sed -i 's/jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1/jdk.tls.disabledAlgorithms=SSLv3/g' /opt/java/openjdk/lib/security/java.security
The essence is to modify the java.security content at the same time when building the business image, and finally achieve the same effect as the third solution
Solution 5: Lower the jdk version
Although this solution can also achieve the effect, it is not recommended. After all, changing jdk may cause other unpredictable problems
Summarize
For these options, because options 1 and 2 fail to achieve their goals, they can only be selected among the three options 3, 4, and 5. Basically, most of them will choose option 4. However, although it is to solve the problem, it still feels that it is not the best solution. The best solution may be to not change the jdk content, but to change it in other ways, but there is no other idea for the time being. If there is a better solution, you can leave a message to let us know