Increased SSL (HTTPS) Access support for Jenkins (Windows/linux)

Objective:

Increased access to SSL (HTTPS) can provide a more secure problem for Jenkins deployed under the public network, and the most obvious benefit should be login and Jenkins-ci.jar calls.

For example, the invocation of Jenkins-ci.jar, generally in Windows through the plaintext account password transmission request is very insecure; for Windows configuration and practice refer to the following article:

Http://www.cnblogs.com/EasonJim/p/6086018.html (This is about how Windows is configured)

Http://www.cnblogs.com/EasonJim/p/6086168.html (This is the practice of jenkins-ci.jar usage)

Discussion on the non-security of self-signed certificates:

Reference: http://www.cnblogs.com/EasonJim/p/6640426.html

Personally, if you want to be truly safe, consider purchasing a certificate issued by an authoritative authority; Although self-signed certificates are unsafe, I feel that a certain degree of encryption will increase the difficulty of the transmission process.

What else can be used to replace Jenkins in SSL (HTTPS) security:

I think there should be no more secure scenario than deploying SSL if you are accessing the web on a public extranet. However, security can be further enhanced by the following techniques:

1, for the deployment to the external network of Jenkins using a VPN login mechanism, only the company's internal personnel can have permission to log on the VPN connection and Operation Jenkins.

2, the whole network management, do not contact the external network.

3, if you want to invoke the Jenkins-ci.jar function, under Linux is recommended to use SSH login to operate.

Increased SSL (HTTPS) Access support for Jenkins (Windows/linux)