История изменений

Приватный ключ не обязательно должен лежать на сервере

Приватный(полный, «закрытая часть») ключ сервера должен лежать на сервере, а клиента у клиента. Публичный (открытая часть) наоборот. Этим достигается взаимный auth. А если на сервере нет его публичного ключа, то он не может представиться клиенту и тому придется довериться основываясь только на том, что сервер оказался по известному адресу.

У openvpn принято использовать сертификаты(которые по сути публичные ключи), где удостоверяющий центр теоретически независим. Хотя многие ленятся и генерируют все прямо на сервере, т.к. там же комплектный easyrsa, но лучше там сгенерировать только ключ сервера и запрос на сертификат. А заверять его можно и на своей машине, где роль удостоверяющего центра сыграет тот же easyrsa, или если не в консоли, то xca (если лениво, то можно и ключ сервера сгенерировать на своей машине). Т.е. даже не используя схему разделения сервера УЦ и клиентов по разным машинам, а используя вместо ленивой схемы сервер+УЦ и отдельного клиента ленивую схему сервер и отдельный клиент+УЦ, безопасность кажется больше.

Приватный ключ не обязательно должен лежать на сервере

Приватный(полный, «закрытая часть») ключ сервера должен лежать на сервере, а клиента у клиента. Публичный (открытая часть) наоборот. Этим достигается взаимный auth. А если на сервере нет его публичного ключа, то он не может представиться клиенту и тому придется довериться основываясь только на том, что сервер оказался по известному адресу.

У openvpn принято использовать сертификаты(которые по сути публичные ключи), где удостоверяющий центр теоретически независим. Хотя многие ленятся и генерируют все прямо на сервере, т.к. там же комплектный easyrsa, но лучше там сгенерировать только ключ сервера и запрос на сертификат. А заверять его можно и на своей машине, где роль удостоверяющего центра сыграет тот же easyrsa, или если не в консоли, то xca. Т.е. даже не используя схему разделения сервера УЦ и клиентов по разным машинам, а используя вместо ленивой схемы сервер+УЦ и отдельного клиента ленивую схему сервер и отдельный клиент+УЦ, безопасность кажется больше.

Приватный ключ не обязательно должен лежать на сервере

Приватный(полный, «закрытая часть») ключ сервера должен лежать на сервере, а клиента у клиента. Публичный (открытая часть) наоборот. Этим достигается взаимный auth. А если на сервере нет его публичного ключа, то он не может представиться клиенту и тому придется доверится основываясь только на том, что сервер оказался по известному адресу.

У openvpn принято использовать сертификаты(которые по сути публичные ключи), где удостоверяющий центр теоретически независим. Хотя многие ленятся и генерируют все прямо на сервере, т.к. там же комплектный easyrsa, но лучше там сгенерировать только ключ сервера и запрос на сертификат. А заверять его можно и на своей машине, где роль удостоверяющего центра сыграет тот же easyrsa, или если не в консоли, то xca. Т.е. даже не используя схему разделения сервера УЦ и клиентов по разным машинам, а используя вместо ленивой схемы сервер+УЦ и отдельного клиента ленивую схему сервер и отдельный клиент+УЦ, безопасность кажется больше.

Приватный ключ не обязательно должен лежать на сервере

Приватный(полный, «закрытая часть») ключ сервера должен лежать на сервере, а клиента у клиента. Публичный (открытая часть) наоборот. Этим достигается взаимный auth.

У openvpn принято использовать сертификаты(которые по сути публичные ключи), где удостоверяющий центр теоретически независим. Хотя многие ленятся и генерируют все прямо на сервере, т.к. там же комплектный easyrsa, но лучше там сгенерировать только ключ сервера и запрос на сертификат. А заверять его можно и на своей машине, где роль удостоверяющего центра сыграет тот же easyrsa, или если не в консоли, то xca. Т.е. даже не используя схему разделения сервера УЦ и клиентов по разным машинам, а используя вместо ленивой схемы сервер+УЦ и отдельного клиента ленивую схему сервер и отдельный клиент+УЦ, безопасность кажется больше.